On 19 Jun 2020, at 10:38, Alessandro Vesely wrote:
consider a mailing list as a publishing organization, which is what it
is.
No, it isn't. It is a Mediator. See RFC 5598.
If article submission happened via HTTP, say, like in web fora,
there would be no reason to talk about From: rewriting.
Take my particular case: I don't get SMTP email from IETF mailing lists.
I point my email client to imap.ietf.org and read the messages directly
out of the mailboxes there. As people send email to the list, the
messages are deposited into the appropriate IMAP mailbox for the list.
Some of the messages (mistakenly IMO) have their Subject's munged, but
not on all lists, and certainly not on the main IETF list. Usually, only
trace info (Received: fields), a set of List-*: fields, an Archived-At:
field, and similar are added, but otherwise, the contents of the message
(including the normal headers) are unadulterated. That's good: I can
reply to the author directly, reply to the list, or reply all as I see
fit, or I can check S/MIME signatures, or I can use the "Add person to
my address book" feature of my client, etc. It all works because nothing
is munged. It is as it should be.
The
fortuitous circumstance that both article submission and the final
distribution happen through SMTP generated the current conundrum.
Why should using SMTP for *message* (not "article") distribution change
anything in the example above?
And let's not pretend that it is just mailing lists that have this
problem. The "resend" feature on my email client breaks if servers honor
p=reject and can't be bothered to check the Resent-*: fields and realize
that I am a legit sender. Alias expansion breaks. The problem is that a
whole set of legitimate and documented features in email were simply
dismissed as unimportant to keep in the first round of DMARC (or, more
fairly, probably weren't properly considered).
It presumably seemed to be easier or less intrusive to tag the
Subject: and leave the From: unaltered.
No, that's rewriting history. The presumption of all Mediator-type
transactions was that the receiving email client was to deal with the
message (the thing with the identical Message-ID) with its original
semantics, adding only Resent-*: or List-*: fields to add the semantic
of the mediation event. Even rewriting Subject: is a problematic hack
which the List-*: fields were created to avoid.
The correct approach should
have been to use the publishing organization's own From:, possibly
adding the author's name or initials to the Subject:. We only realize
that mistake now, after the introduction of email authentication.
Yes, we kept using the wrong arrangement for 40+ years. That is not a
good reason to persevere.
No, sorry, you've got the history entirely on its head. For 40+ years,
we had a set of features of the email system which allowed an email
message to be copied and/or moved around in loads of different ways (in
archives, in IMAP stores, in mail clients), and one of those ways was
always "reintroduce the message back into the transport system" using
trace info in the message header to see the details of that
reintroduction. DMARC came along and decided that that particular set of
features was not worth addressing, or too hard to address, or maybe
didn't realize that such features were going to be a problem.
Maybe it's time to abandon that set of features. I personally don't
think so, but I could be in the rough part of the rough consensus. But I
do think that set of features can be preserved with a bit of work, and I
think that work is worth doing. But if we are going to abandon those
features, a better argument will need to be made than "Oh, in retrospect
we realize that email was doing it wrong for 40+ years." That argument
is bogus.
pr
On Thu 18/Jun/2020 21:01:29 +0200 Hector Santos wrote:
Alessandro,
There are long time solid reasons why the "Local.From" field needs to
be stable. In particular, with local messaging, unless the local
system allows for anonymous entry of the Local.From field when
creating a Local message, there is a MUST for a 1 to 1 association
with the account.
If local mail is exported for a external network, it doesn't matter
what mail network it is, you really don't want to introduce the idea
of allowing the changing of the Network.from field and making it
anonymous or disassociated with the original source. The domain is
associated with the source of the message, and the user part of the
address reflects the user account at the domain. There are good
reasons for that. Lets say the user is causing a problem on a
remote
system. Using the network.From, the remote system could contact the
original system and issue a complaint. If we were "free" to remove
that idea, it be would harder to trace it. DKIM allows you to
lock
that field down so that it can't be tampered with.
You have to understand the long time pov of developers that have been
at this for 40 years. Every system I have worked, the different
networks, it was the same thing -- leave the from field alone! Do not
make it "anonymous" or capable of being an "unknown."
Its the same for Instant Messaging, for Chatting, the TELEPHONE, the
Caller ID, etc, it is a TABOO to change the "From" entity.
If you want to continue your line of logic to rationalize Rewriting,
then you need to make it "protocol complete" to help keep the
association of the From field with the original source intact. But
more importantly, it should have get permission from the original
domain in order to rewrite. This can be done with a DMARC tag
extension:
DMARC p=reject|quarantine ... rewrite=0|1
The default sides with highest security -- No Rewriting. But if the
domain wishes to allow for rewriting, then it should explicitly state
it in this policy record, rewrite=1.
This is something I could possibly support IFF the originating domain
allows it. There would other things to consider to tie the loose
ends,
but the #1, would be the rewrite=1 tag.
--
Pete Resnick https://www.episteme.net/
All connections to the world are tenuous at best
_______________________________________________
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc
