Non-Resolving HELO names

[LMStone]

So much for having standards then Mark And I do take your comments on board and have seen similar but otherwise how do companies learn.

Well, I hear what you are saying and in principle generally agree. But standards do (and IMHO should) evolve to accommodate changes in technology and the marketplace.

At a time when most folks ran their own mailservers, I think strict adherence to this standard made good sense for a number of reasons. Certainly in years past we ourselves made hundreds of calls and emails to email admins whose systems didn't HELO to match their MX.

Today, strict adherence to this standard is nigh impossible for large complex mail systems, like those of large ISPs and outsourced providers like Postini.

Plus, the tradeoffs are actually beneficial IMHO for large systems NOT to adhere to these standards.

Consider a large ISP whose gateway MX is "smtp.isp.com". In reality, that's just a load balancing proxy for a dozen email servers behind it, e.g. "mail1.isp.com" etc.

For the ISP, without the load balancing proxy, they'd need to set up a dozen MX records for every domain they host.

For systems sending email to any of the ISP's mail servers, if one of the ISP's mail servers is overloaded, the sending mail server gets loaded too waiting for a timeout, then has to do another DNS lookup to find the next MX record, and then try again. Of course, at that point, every other sending email server is doing the same thing and so that specific ISP's MX now gets overloaded. Mail flow slows, the ISP's mail servers are underutilized collectively, and sending mail servers are overloaded with unnecessary timeouts and extra DNS lookups.

Then too, adding or deleting mail servers to/from the ISP's farm requires a gazillion changes to public DNS without a load balancing proxy. It gets a little hairy...

One key goal of the original requirement for MX/HELO matching was to ensure that we all knew for sure that the mail server we were trying to reach was the mail server we actually wound up talking to. This was long before spam volumes made things like valid recipient checking mandatory (remember how we all used to have "catchall" addresses as a matter of course?). And this was also at a time when many DNS "servers" were nothing more than the /etc/hosts file!

Nowadays, most mail servers will only accept mail for valid recipients, so if we as a sending server wound up talking to the wrong mail server, we'd get an NDR anyway.

So, the need to correctly identify a mail server driving this requirement originally has diminished greatly; changes in technology make adhering to this requirement nigh impossible for large systems (and in some cases results in better resource utilization too for both sender and receiver), and; we have lots more effective tools in our arsenal for screening spam without generating the false positives that this test will.

In other words, while I am generally a proponent of standards adherence, this standard needs to catch up with the world as it exists now IMHO.

Hope that helps,
Mark

[bhwong]

Thanks Mark for providing us with an good insight of this issue with huge ISPs. Tiny ISPs have the opposite problem with standards... sharing 1 IP with multiple domains, ensuring that domain and IP will not match up except for 1... :P

[rwcanary]

Its not my clients MTA causing the issue, it is my client's client. Something I have no control.