On Sun, Jun 21, 2020 at 1:32 PM Dave Crocker <dcroc...@gmail.com> wrote:
> > When first specified, Sender: was to cover the case of someone doing the > online work, on behalf of authors who weren't online, or at least not > online for processing the message. Back in those days, that was not > uncommon. Even if the author officially had an online presence, they > often did not do the typing. > > It's important to note that in those times the "Sender:" was almost certainly in the same organization/location/address/namespace as the author. If that were still true today we wouldn't be having this discussion because the RH side of the email addresses would align. > For most email, From: and Sender: are the same person (and the same > email address.) This fact was the reason the original specification of > Sender: in RFC 733 only required an explicit Sender: field be present > when the addresses are different. > > For today, these same abstract constructs have -- or should have -- only > slightly different application. From: is still supposed to be the > author, which remains the creator of the (original) content. Sender: > could be any separate party responsible for processing the message "Processing"? That covers a whole lot more than sending. A security appliance "processes" the message but is clearly not the Sender. > . > > So, in abstract terms, if I go to a greeting card site and have it send > a greeting on my behalf, the From: field should be my own email address > and Sender: should an address at the greeting card company. But I said > 'abstract' because current realities mean this isn't as useful an > arrangement as the theory intended. > Now you are in a space I know a tiny bit about. There's a little bit of history here, starting with the FTC spam workshop in 2003 and the FTC email authentication workshop in 2004 we saw a lot of changes starting to occur in the email authentication space. The FTC was forcing things by indicating that if the private sector didn't come up with solutions, the FTC was going to regulate. SPF took a spot in the limelight and DK and IIM were merged to create DKIM. A number of people on this list were involved in all the happenings. Anyways, I wrote a 46 page document for internal consumption at the greeting card company I worked for. At the time, pretty much all greeting card companies sent email in the manner you describe except that many didn't even bother with Sender... and the emails typically got through to the recipient. In my analysis, I posited that there would be drastic changes coming in practices for greeting card sites along with news sites (share with a friend) or sites that had a refer a friend function (and which typically sent the email using the email address of the person doing the referring on the theory it would result in more opens. In any event, my thesis was that all of these types of websites would have to start sending emails as themselves rather than using an email address not their own. This was specifically linked to these nascent email authentication efforts. In 2007, the Storm Worm started spewing "greeting card notifications" (along with other sites) purporting to be from a variety of greeting card sites. The volume of these sends was orders of magnitude greater than any greeting card site was sending itself. This caused management to ask me what could be done about this problem. We implemented changes like strict SPF and DKIM across the board for all our end user facing websites (mail), moving all our employees (with the exception of role accounts and a handful of user accounts that responded directly to end users or partners and publicizing to receiving domains and security companies what we were doing and that if mail claiming to be from our domains failed to pass either SPF or DKIM, throw it away. Absent the feed back loop and the formal definitions in the standard, this is the essence of DMARC. If someone cares to look back in the DKIM-OPS list from that time frame you can find posts from me making those assertions. At roughly the same timeframe, Pat Peterson, who was still at IronPort, organized a small group of senders (mostly financials and a greeting card company), a couple intermediaries (like ReturnPath and eCert) and some major receiving sites (like Yahoo! and AOL). PayPal and Yahoo! at the time were working on a private peering solution which was successful. This all eventually became the DMARC "team" and later dmarc.org. It is important to remember that both SPF and DKIM function at the domain level, not the individual account level (with the exception of edge cases like a domain which is a personal domain with a single user account). Yes, there was the d= vs i= debate with DKIM... and i= lost out in practice. Today you won't find any (major) greeting card site sending email in the way you describe. This isn't because they wanted to change. It's because they were forced to change. Email authentication has a network effect that in essence makes unauthenticated mail "second class" from a receivers point of view. Yes, there are certain types of mail scenarios (MLMs for example) that are problematic, but one always has to ask, for whom? Some in the MLM community responded to the changing environment by saying "We were here first so go fuck off with telling us to change how we do things". Yet MLMs have changed in various ways in attempts to deal with the environment presented by changing practices, particularly by major receiving sites and the security industry. > > I believe this is because Sender: is not reliably present. Hence, it > literally cannot be relied upon. The Sender field is not created > reliably to indicate such distinctions and the receive side does not > reliable note the distinctions. > I absolutely disagree. It's not because Sender: is not reliably present but because Sender: is inherently unreliable because unless it is in the same domain space we have absolutely no way to validate the relationship between Sender: and From:. This was the problem inherent in the SenderID PRA algorithm. I could and did send emails to the folks who were promoting SenderID at MS using their email addresses and random nonSPF publishing domains as the Sender: to consistently achieve a neutral from the PRA algorithm. Until and unless there is a way to specify such a link, any proposal to rely on Sender: is doomed to failure. And no, that does not mean I think Hector's proposals regarding Sender: are valid approaches. > > > > For a newspaper, if you pardon the analogy, the masthead is more > > visible than columnist signatures at the end of the articles. For a > > mailing list, publisher visibility used to be provided by subject > > tags, leaving the From: intact. Why? Presumably, because it just > > worked that way. However, if the MLM is the system responsible for > > writing, not modifying From: should be considered a violation. MLMs can be both at the same time. Digests vs individual (unmodified) messages. > If a Mediator makes 'substantial' changes to a message, then it can be > considered a new and different message? Yes, but note that we have no > objective criteria for this. That's why I class this reference to > 'publisher' as a business issue rather than a technical one. (And an > ethical one, as some wayward journalists discover when they claim to be > quoting someone but it turns out the reporter invented the content.) > The real question is what works, not whether it is a business issue vs a technical issue. If there is a standard that works, great. If there are heuristics or algorithms that work, they will get implemented whether they have been standardized or not. To the extent that standards bodies provide meaningful solutions in (somewhat) timely manner, they will remain relevant to a given (problem) space. > > However I think that referencing the role of an MLM as 'publisher' can > be helpful to remind us that MLMs have their own agency and can, > legitimately, make all sorts of changes. Whether authors and recipients > like those changes is a non-technical matter. > At the end of the day, mailbox providers will determine the outcome of the subject of these discussions based on how they handle and treat mail passing through MLMs and whether there is authentication they find useful (as one part of determining how they will treat mail streams and individual messages within those streams) > > The practical problem with From: field munging by MLMs that are > otherwise trying to relay a largely-unmodified messages, is that they > effective destroy author information, by putting in a different email > address. > Destroy? or modify? As long as the original email address is available in some identifiable form in the received email message then it is possible for MLMs to work in a manner akin to how they work today. Yes it involves rewriting code and logic to support those changes but there you have it. > > In practical terms, today, the MLMs arguably don't have a choice. But > it still can be helpful to understand the problems created by this > alternation. > It's not a technical issue for MLMs, it is a business issue at its essence - change or don't change. Such change can be on an individual basis (or not) or it could be standardized. > >> My understanding of the meaning that DMARC added was, "The author of > >> this > >> message, as expressed in the From: field, always has their messages > >> properly > >> signed by the domain in the From: address." You seem to be saying > >> that, no, > >> what DMARC did was changed the semantic to be, "The From: field now > >> represents the transmitter of the message (as used to be expressed in > >> the > >> Sender: field when present), not the author, and that transmitter > >> always has > >> their messages properly signed by the domain in the From: address". > > For reference, I consider this an accurate summary of why I say that the > From: field semantic is changed as a result of DMARC. Specifically so > that mailing list mail can be delivered. > And yet Sender: can still be the transmitter as long as they are in the same RH address space OR can sign the message with a valid DKIM key from the From: address domain space. Of course, MLMs putting their own email address in the From: is a change but I'm not sure it quite matches the semantics you suggest. > > > > Sender: was not meant to be the transmitter in that sense. It was > > meant to be the secretary who writes on behalf of a responsible person > > or system. > RFC 5322 has preserved the semantic of the Sender: field: > > "The "Sender:" field specifies the mailbox of the agent > responsible for the actual transmission of the message. " > > I consider that to be exactly the role the MLM is performing. > Sender: can still be a useful field but not necessarily from an authentication POV absent some way of determining whether the purported Author authorized the Sender to send the message on their behalf. > > > > RFC 5322 says display names are "associated" to a mailbox. > As long as the display name is free form it is not associated with anything in particular other than the message which contains it. > > I don't see such language in RFC 5322. In fact, other than the ABNF for > display-name, I don't see any explanation of its semantic. > +1 Michael Hammer >
_______________________________________________ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
