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.
--
HLS
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.
Cheers,
Steve
_______________________________________________
ietf-smtp mailing list
ietf-smtp(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf-smtp
_______________________________________________
ietf-smtp mailing list
ietf-smtp(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf-smtp