Pete Resnick wrote:
There are cases where it is REQUIRED (section 1 of 2119) and
cases where "there may exist valid reasons in particular
circumstances to" not have a Sender, "but the full implications
must be understood and carefully weighed before choosing
a different course" (section 3 of 2119).
Right, and that can be difficult if the sender has no idea
about auth* schemes building on accurate info (SenderID and
maybe some future DKIM SSP scenarios).
- The agent responsible for the actual transmission of the
message is the company lawyer who vets every e-mail
message before sending it out. But the lawyer's identity
should not be revealed to the rest of the world for
security reasons.
They could use a role account for this task. Or pretend that
the author submitted the mail when the real Sender would be
in the same domain (i.e. most likely irrelevant).
- The agent responsible for transmission is *really* hard to
determine. A particular system may have an audit log which
can figure out who sent it later, but that information is
unavailable when the message itself is being sent.
RFC 4409 8.1 is clearly an OPTION, and as long as it is about
the same domain I don't care about SHOULD vs. MUST. But for
a Sender in another domain I'm not sure about this conclusion:
It certainly lowers interoperability to not have a Sender
when there is a single author and we know the transmitter is
different from the author, but only insofar as we have lost
information. But it does not eliminate interoperability.
FWIW, the technical part of the SPF vs. SenderID controversy
boiled down to "4409 8.1 is no MUST, besides envelope sender
and Sender can be in different domains even if the Sender is
correct".
And for DKIM-SSP they now apparently arrived at the conclusion
that SSS is actually ASP (= s/Sender/Author/ in the acronym).
The lost information can be critical for schemes assuming that
it is present. 2822upd could note something in the direction
of your examples, showing that such assumptions are erroneous
to start with. I'm not hot about it, but it is good to know
that the SHOULD in 2822upd 3.6.2 is *intentionally* no MUST.
Frank