[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: 2822upd-06 Sender
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