RE: [dmarc-ietf] Identification of an email author (was - Re: IETF Mailing Lists and DMARC)

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



> I think technical fans of email perhaps attach more import to the rfc5322.from field than

> does the average user.  Certainly, downsides exist.  That said, facebook notifications
> today all come from the same per-user address, with the actual commenter as just the

> display name.  Various forum software, email ticketing software, the email notifications

> from various web based messaging systems, they all fail to apply authorship in how you say.

 

I think of myself as a technical email guy, but I’m surprised at how much of an average user I am. If I were to get an email from someone (or I guess myself) on this list like this:

 

From: Terry Zink via IETF-DMARC <dmarc@xxxxxxxx>

This already happens from other lists I am on, I don’t think twice about it. I sort of even think “Hey, that works better for me!”

 

And if there were something like this in other headers that retains the original senders:

 

Reply-To: originalSender@xxxxxxxxxxx
Sender: dmarc <dmarc-bounces@xxxxxxxx>

 

Then so much the better, I don’t even notice them unless I hit Reply. As Brandon says, I’ve already been conditioned to look for the same email address, for example I get this from LinkedIn:

 

From: Example Person (via LinkedIn) <messages-noreply@xxxxxxxxxxxx>

 

I get that some people don’t like how the From: address no longer reflects the “real” sender, but I don’t just use the email address to identify a sender. I use the Display Name, too, and putting someone’s name and the source into the Display Name is helpful.

 

That doesn’t mean there aren’t better options. But this workaround – at least for me – is not that painful.

 

--Terry

 

From: dmarc [mailto:dmarc-bounces@xxxxxxxx] On Behalf Of Brandon Long
Sent: Thursday, November 3, 2016 4:04 PM
To: Dave Crocker <dcrocker@xxxxxxxx>
Cc: dmarc@xxxxxxxx; IETF <ietf@xxxxxxxx>
Subject: Re: [dmarc-ietf] Identification of an email author (was - Re: IETF Mailing Lists and DMARC)

 

 

 

On Wed, Nov 2, 2016 at 3:51 PM, Dave Crocker <dcrocker@xxxxxxxxx> wrote:

On 11/2/2016 2:58 PM, Brandon Long wrote:

The difference is mostly cosmetic, though depending on your mail client,
there may be other downsides.  And it may violate RFC 5322.


Brandon,

You know that I know that the attacks that generated the use of DMARC, which is causing the current situation, are serious.  I'm mentioning that here to make sure the context for what follows is clear...

Email is communication between an author and one or more recipients.

Everything in between them is 'overhead'.  The overhead functions need to be careful to avoid cavalierly reducing the utility of email, even as the changes are meant to aid in the use of email.

Identification of the author and recipients is meaningful to them. That's not 'cosmetic'.

And software tools employed by users take advantage of this identification, for searching and for organizing.

 

Including Gmail, which doesn't handle this workaround well, either.

 

In a highly diverse world, one of the problems of being a very major player is that it becomes far too easy not to see all the diversity or to appreciate its import to others. After all, most of that diversity is seen as such a tiny percentage of the activity. This is the essence of ethnocentrism.

Changing the contents of the rfc5322.From field is changing basic statements about authorship.

Perhaps there's no practical choice right now, but please let's not be cavalier about its import.

 

I think technical fans of email perhaps attach more import to the rfc5322.from field than does the average user.  Certainly, downsides exist.  That said, facebook notifications today all come from the same per-user address, with the actual commenter as just the display name.  Various forum software, email ticketing software, the email notifications from various web based messaging systems, they all fail to apply authorship in how you say.

 

Yes, mailing lists have existed in this form for some time, and they are a good and vital system, and the downsides are real.

 

Note also that I imagine that mailing list software which supports EAI messages might also need to munge the From header to downgrade the message for delivery to non-EAI enabled receivers.

 

I'm not sure if my comment was heard in the recent ARC round table, where folks were questioning the overall complexity of ARC, but I'm fairly serious in saying that all of our discussions on work arounds and technical methods for trying to make DMARC work with mailing lists, and from header munging is by far the simplest.  No trust/reputation systems, no manual whitelisting, no "magic sauce", no new software to be installed by receivers.

 

ARC will add greatly to the size of mail headers, which some folks on mailop still think should be tiny and talk about automatically marking large headers as spam.

 

ARC will add greatly to the privacy concerns which were raised last week on the DKIM IETF list, where now not only is a message have attestation of origin, but that attestation will survive some amount of forwarding/modification, and the path it took will also be attested to.

 

ARC will require new software to be installed by mailing list providers and any receivers who implement DMARC.  Even after being installed, there is still more work in order to allow the mailing list messages through.

 

Brandon

 

 


[Index of Archives]     [IETF Annoucements]     [IETF]     [IP Storage]     [Yosemite News]     [Linux SCTP]     [Linux Newbies]     [Fedora Users]