John C Klensin <john+smtp(_at_)jck(_dot_)com> wrote:
Two very general observations:
(1) You have just explained --whether you intended to or not--
why it is much better to tie policy information to the domain in
the MAIL command than to the one in the EHLO/HELO command.
Certain kinds of policies need to be tied to MAIL-FROM; others
should be tied to EHLO, IMHO.
When domain managers want to state that mail claiming to be
from theic domain should (ordinarily?) be sent from particular MTAs,
policy tied to MAIL-FROM is much better. (Of course, it's not quite
right: tieing such policy to an end-user-visible header would be
best.)
When domain managers want to state a policy about DSNs addressed
to their domain, MAIL-FROM is exactly the right field to tie it to.
OTOH, when MTA managers want to say, "We virus-check all
outgoing email," policy tied to EHLO is a much better tool.
(It has always bothered me when SPF proponents claim it's ever
reasonable to tie the same SPF record to different fields.)
(2) Even more generally, the various efforts to design and
specify verification and validation procedures for email really
need to start, IMO, with an understanding that the current specs
and installed base are a given and that a combination of the
robustness principle and operation experience prohibits action
based on a possible protocol-lawyer's reading of those specs.
I don't think John K means quite what that says: I think he
means that anything allowed by the current spec will need to
continue to work for _some_ sending and receiving MTAs.
making significant changes in the standards, changes that would
invalidate many or most existing conforming implementations, to
reflect your ideas of how things would work in a better world...
well, probably isn't going to happen.
Such things certainly can happen by route of SMTP extensions
agreed to by both sending and receiving MTAs, and that is always a
better way to approach things than trying to change the base spec.
(Yes, I know I have lobbied to relax some things in the standard
that I have reason to know are somewhat commonly ignored; but I
have also stopped beating the horse when it is pronounced dead...)
As we go forward with 5321bis, I suggest we make sure that there's
ample room for extensions to fix known problems like whether to
trust a return-path, what's the best way to report emails caught
in spam filters, differing policies for different recipients in
the same transaction, and establishing/reporting reputation info.
We might also do well to decide whether chartering a WG to work
on such extensions would be wise. (I firmly believe it is possible,
but that it needs to be quite separate from advancing 5321 to
full Standard.)
--
John Leslie <john(_at_)jlc(_dot_)net>