[Top] [All Lists]

Re: [ietf-smtp] Private Domain Names and the EHLO/HELO Command

2013-03-26 22:53:54
As a follow up:

You also have security protocols like SPF which may do HELO/EHLO check and IMO, the advanced SPF implementation will skip the overhead if it doesn't have a dotted domain (no point if it fails DNS). So I recommend not to use a private dotted domain when there is 100% awareness it will 100% fail at 100% remote receivers. Consider the receiver overhead in all this.

BTW, what is meant by "Dumb" smtp client?

- its only allows or does not allow manual setting of helo/ehlo field?
- its does or does not do automated ehlo field setup?

As Steve pointed out, even a smart automated client that detects a public domain machine or uses the bracketed IP literal can fail when a NAT is involved. So even the smarter ones are too smart. These clients need to be "dumb" down to also offer manual settings. This is exactly what happen with Mozilla's TBIRD.


On 3/26/2013 9:20 PM, hector wrote:
Agree, which is why I got the Thunderbird folks to add a fix for the machine name configuration so it can be hard coded to the NAT public address.

In the mean time (and for the general others), for a submission server, I suggested that the EHLO required check allowed by a submission server be relaxed on the basic idea that eventually AUTHentication will take place as required by a submit server. So that is what we have - For port 587 operations, since AUTH is required, the EHLO check is skipped.

For a dumb or any client really , at the very least it (ehlo/helo value) needs to be manually settable or as I stated like Outlook will do, use a undotted name like the machine NETBIOS name, if any. I think most clients will not bother (it can't, nothing to solve).

I am just suggesting what might be the least harmful.

- If you use brackets, you must consider IP checking will be done.
- if you use dotted names, you must consider some DNS/IP checking domain matching will be done, although enforcement is not practiced at this point.

Either it allows for manual setup for an IP literal or a NAT router public domain or use a netbios/undotted name, one that will not add overhead for receivers believe it can check it.

On 3/26/2013 8:55 PM, Steve Atkins wrote:
On Mar 26, 2013, at 5:50 PM, hector <sant9442(_at_)gmail(_dot_)com> wrote:
2) If squared bracketed, by specification assume a dotted IP address and by SMTP specification this allows for a simple SMTP compliancy check to verify the IP of the connection matches the provided IP literal. You are allowed to do this because when a IP Literal is presented, it MUST machine the connected client IP address. This yields a pretty high spam rejection with 100% zero false positives after at least 10 years of automated operations.
It'll fail all the time in the case of an MUA behind a NAT - which is going to be pretty common in the case we're discussing of a dumb SMTP client submitting to a smarthost.


ietf-smtp mailing list

ietf-smtp mailing list