ietf-smtp
[Top] [All Lists]

Re: [ietf-smtp] Variable HELO name, was DSNs

2020-04-26 09:37:45
On 26/04/2020 00:41, John C Klensin wrote:

Suppose there were correspondents, or even domains, for which I have found
read receipts useful and something I'm willing to let them use.  So, because
of them, I advertise the availability of that feature in the EHLO response.
When the MAIL command comes along and doesn't contain that domain or
mailbox, I reject the request.  Now, which mailboxes or domains to accept is
an operational decision, but the behavior, AFAICT, is fully conforming and
it certainly don't mean that the features doesn't work, just that I have an
operational policy prohibiting its use in most circumstances.

There are lots of ways to offer NOTIFY=SUCCESS selectively depending on what
you're trying to accomplish. Keeping in mind that it's a RCPT TO parameter,
another possibiity is to only allow it on domains within the ADMD.

Given all the possible uses and ways of authorizing them, it is perhaps better
to focus on the one problematic case: Relay between ADMDs where the server
doesn't trust the client.

Wow, I never tried that at home!

A decade ago we fantasized about a Verified Hello, whereby:

   Non-empty arguments of the MAIL FROM commands are restricted to
   addresses whose domain part consists of the authenticated Domain.
      https://tools.ietf.org/html/draft-vesely-vhlo-06#section-3.4.1

Otherwise, the reply code is ambiguous.  For example:

  4xx HELO name/MAIL FROM inconsistency, try another session.

AFAIK, the HELO name is practically constant for most mailouts, so the above
reply will make the relevant message bounce for days, until timeout.

The EHLO name is necessarily consistent with the DNS entries for the client IP.
It most certainly is not reliably the same as the MAIL FROM domain, especially
when operating at scale. And foccing a disconnect/reconnect in such cases is
highly problematic given that we have no means of indicating that's what's
needed, and even if we added one, no existing client would understand it.

                                Ned

_______________________________________________
ietf-smtp mailing list
ietf-smtp(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf-smtp

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