Franck Martin writes:
> I wish the mailbox-list syntax in the From would be deprecated for
> the mailbox syntax, but it is unlikely to happen, may be when
> RFC5322 gets revised (under Security, end to end, IPv6 experience),
I don't understand why any of those experiences would cause RFC 5322
to be revised in this way. The problem is not in the protocol used to
implement the network, but rather in the structure of the network of
people involved. Most email networks-of-people don't involve a use
case for multiple mailboxes in From, but some do (see below). OTOH,
if you really need to pin responsibility for message origination on a
particular person, the Sender field is the appropriate field.
Even in the case of DMARC, as far as I can tell, for the intended use
case of transactional mail there is little problem with throwing From-
with-multiple-mailboxes into the "unauthenticable" pool, and rejecting
on that basis if you want to. I see no reason to disallow this useful
feature in RFC 5322 when it is better done in DMARC, or perhaps in the
lower level protocols.
> but from an operational point of view (if you want ops to come back
> to IETF, listen to them :P ) you don't loose any useful email if
> you reject emails with multiple mailboxes in the From.
Please take more care with your pronouns. I am not a member of your
"you".
I know for a fact that if every MTA rejects because of multiple
mailboxes in From, mail I consider important will not be delivered.
I know and consider it important because I write it on behalf of an
anti-harassment committee, and it's important that the members be
individually identified[1] and individually reply-able[2]. There
are other ways to accomplish these goals simultaneously, but using
multiple mailboxes in From is all of most economical, most intuitive,
and most beautiful. (I occasionally do it in other cases, but this
case is special because it is of true utility to the recipients.)
Given that you say this practice is rare and mostly harmless in your
own experience, I don't see that the costs of treating such messages
as an unauthenticated are high.
Also, your experience is probably far less generic than you think, if
it's based on LinkedIn. LinkedIn is a social network based not on
groups but on individual links (although it provides groups, IME they
are not entities in themselves in the way that bureaucratic committees
are, but rather aliases for a "me-to-many" set of bilateral links
based on common interest rather than individual identity). It is no
surprise to me that the vast majority of messaging at LinkedIn is
related to *one*-to-one or *one*-to-many communications. The reverse
relationship ("many-to-you") is more likely in a bureaucratic context
(and certainly is useful for me personally).
If you *aren't* speaking of LinkedIn, or that's not a correct
analysis of how LinkedIn works, feel free to enlighten us.
Footnotes:
[1] We have ex oficio personal responsibilities to maintain student
privacy that are actually a special exception to the normal faculty-
administration relationship.
[2] Not a group address -- it's not unheard of for bad actors to end
up on such committees, although not in my tenure, thank heaven.
_______________________________________________
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc
