ietf-smtp
[Top] [All Lists]

Re: RFC 5321bis / 2821ter

2009-01-23 16:52:31

At 06:37 PM 1/23/2009 +0100, Alessandro Vesely wrote:

Paul Smith wrote:
To get around [meaningless address literals], you use SMTP
submission with SASL (OK, that requires EHLO anyway, but the EHLO
name is irrelevant in that case).
IMV, if it is expected by the base standard that the EHLO data is
to be used for anything other than logging/tracing, then these
considerations and more need to be looked at carefully.

That's apparently the split that Message Submission envisions. Either the 
client validates a name using a password, or it uses a globally registered, 
hence meaningful, name.

How "meaningful" can a name be? It shouldn't be overwhelmingly difficult for 
an MTA to put after EHLO a FQDN that can be resolved to its IP address. 
Probably the standard cannot be so rigid, but including careful considerations 
of what circumstances may or may not allow what names, seems a good idea.

David went so far as to ask for a reputation-ID after EHLO. I'm not sure 
whether that would ease or complicate setting up an MTA.

Just to be clear, I'm not suggesting anything that would complicate setting up 
an MTA, require new mechanisms, etc. (unless you mean complicate things for 
crooks who might have a hard time acquiring a reputable ID, or for naive users 
who want to send email directly from their cameras, without any reputable 
intermediary service.)  I have yet to see any sensible use-case that would be 
complicated by a requirement that the HELO/EHLO name end in a registered, 
verifiable domain name.  If I want to receive email directly from my coffee 
maker, I'll add it to my whitelist.

I am aware that many otherwise legitimate transmitters currently use invalid 
HELO/EHLO names, and I don't reject their mail.  I do, however, send their 
messages immediately to the spam filter.  If you want reliable delivery, you 
need a valid identity, one which we can verify in DNS, and to which we can 
assign reputation at any level we please.

<Prev in Thread] Current Thread [Next in Thread>