Re: [dmarc-ietf] Header munging: A solution proposal for alternate authentication
On Tue, Jun 23, 2020 at 4:08 PM Douglas E. Foster wrote: > A few issues remain: > > How does the incoming filter prove that the message is really from the list, > rather than someone spoofing the list? Since the RFC5321 M and the Was there supposed to be more to this line? -MSK ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] What if... Sender:
On 6/23/2020 4:14 PM, Jim Fenton wrote: I do have a concern about Sender:. It has existing semantics defined in RFC 5322 Section 3.6.2, and this proposal might conflict with that I don't think it conflicts at all. So it will help for you to explain your concern in detail. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] What if... Sender:
On 6/23/20 11:49 AM, Dave Crocker wrote: > So... what if DMARC's semantic were really for the Sender: field? If > a message has no separate Sender: field, then of course the domain in > the From: field is used. > > The would produce obvious possibilities: > > From: someone@goodplace.example > Sender: someone@goodplace.example > > and > > From: somone@goodplace.example > Sender: some...@mlm.example.com > > where there might be a dmarc record for mlm.example.com > > The modification to DMARC would be "look for Sender: and if it isn't > present, look for From:. > > Obviously, mlm.example.com might instead be badactor.example.com. > > but we already have to deal with cousin domains, and DMARC does > nothing about them. > > So if Sender: wouldn't be as useful as From:, why not? This makes a lot of sense to me, assuming of course that the WG comes to rough consensus that alignment specifically with the From: domain isn't necessary. (My personal position is that it's not.) I do have a concern about Sender:. It has existing semantics defined in RFC 5322 Section 3.6.2, and this proposal might conflict with that (IETF's current MLM usage may, as well). But that possible problem could be avoided by inventing a new header field (I can't believe I'm suggesting that), it could be DMARC-Sender: or something like that. If we're going to avoid From: rewriting, we need to have something that specifies where to retrieve the DMARC record from. But as stated above, [DMARC-]Sender: could be badactor.example.com, so it should be clear that DMARC is not going to prevent bad actors from doing anything. It is still useful as a reporting mechanism to detect unintended breakage of message authentication. But I can't think of a reason that the policy mechanism is useful at all. -Jim ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Header munging: A solution proposal for alternate authentication
I believe this document provides a path forward for solving this problem, and it has relatively low complexity of implementation. Doug Foster Current situation Incoming mail filters options when evaluating mailing list messages:Filter evaluates the message as if it is a direct message from the list domainThis is the header munging solution that creates problems for the MUA. This can also be achieved if the sender uses SRS encoding of the RFC5321 MailFrom address, and the incoming filter does no evaluation of the “From” header address.Filter evaluates the message as if it is a direct message from the originator domain, ignoring the evidence that the message came from servers on the list domain, but accepting the message as long as it has a verifiable DKIM signature for the “From” header address. This is the situation when a DKIM-signed message is relayed without modification.Messages may be blocked by the incoming filter because the list members are viewed as unfamiliar and therefore untrusted senders.. An ideal filtering configuration should recognize that there are three potential mail flows, not two.In an ideal world, all three should be identifiable uniquely, since the recipient organization may wish to apply differential policies:Direct messages from the list domain.Direct messages from the originator domain.Forwarded messages from the originator domain through the list. As long as the mailing list applies signature-invalidating changes, Any option requires that the incoming filter chooses to given enhanced trust to the list domain. Specific aspects of that trust:The list performs no deception. Header records are relayed legitimately.The list inserts no malicious content.The list has reasonable controls on list enrollment.The list has reasonable controls to ensure that list submissions are really from the stated email address.The list applies its best effort to block content that the recipient systems would find objectionable.If objectionable content is detected, the fault should be attributed to the originator, not the list domain, so that list message from other originators will continue to be accepted. Once trust is granted to the list, SPF and DKIM checking of the originator becomes relaxed:SPF and DKIM checking can be computed using relayed header information, because the incoming filter trusts that the headers are not fraudulent, orSPF and DKIM checking can be omitted, because the incoming filter trusts the controls applied by the list. A few issues remain:How does the incoming filter prove that the message is really from the list, rather than someone spoofing the list? Since the RFC5321 M___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
[dmarc-ietf] What if... Sender:
Folks, This note is partially triggered by Mike's note this morning, but isn't specifically responding to it. Rather it tries to elaborate on a premise I've been implying but haven't been explicating: What if the rfc5322.Sender field were typically/always present? Or at least, what if it were always present for domains publishing DMARC records? What if messages generally had Sender: fields, even when they are the same as the email address of the From: field? So for such domains the From: really would only be the author information and the Sender: would be the operational handling/sending information.(*) The thrust of my reference to making a separate Sender: field prevalent is an assumption that the patterns of evaluating email addresses could adapt to take advantage of the reliable distinction. For one thing, it could clarify the nature of the information used for filtering. Currently we conflate 'handling agent' (or 'transmission agent') information with 'authoring agent' information. This leads to statements about end-user effects that actually are fundamentally wrong, even as the use of supposed author address information is demonstrating filtering efficacy. What would happen if filtering agents had an explicit distinction between 'author' and 'sender'? It might be claimed that they already do, since the DKIM d= field refers to a handling agent, rather than author, and is explicitly independent of any other message address information. So, why isn't it reasonable, for example, to have DMARC publish a record declaring a requirement for a DKIM or SPF record, independent of From: field alignment? That is, publish a record that says all mail by agents of that domain is always authenticated? It's because the signature needs to be tied to a field that is already 'interesting' and always present. Otherwise there is no way to know what domain name to look for. In practical terms, the only available choice has been From:. First, it certainly has an interesting semantic -- but really semantic/s/ -- for the address, and second, it's always present. So... what if DMARC's semantic were really for the Sender: field? If a message has no separate Sender: field, then of course the domain in the From: field is used. The would produce obvious possibilities: From: someone@goodplace.example Sender: someone@goodplace.example and From: somone@goodplace.example Sender: some...@mlm.example.com where there might be a dmarc record for mlm.example.com The modification to DMARC would be "look for Sender: and if it isn't present, look for From:. Obviously, mlm.example.com might instead be badactor.example.com. but we already have to deal with cousin domains, and DMARC does nothing about them. So if Sender: wouldn't be as useful as From:, why not? d/ (*) Mike took exception to my using "processing" as a term for Sender:. He's probably right and it might be worth some separate discussion to make sure there is useful and precise language to cover what the semantic of Sender: should/must represent. There is a continuing problem in the industry that the word "sender" is used to cover all sorts of agents, from author, to originating MTA, to Mediating MTA. Should it be 'any agent that touches the message' or 'any agent the does a sending operation of the message' or 'the specific agent the posts the message into the mail handling system' or something else? Note that for mail going through a mediator, there are at least two entities qualifying for the 'posting' definition: The author's originating MSA and the MLM's MSA. -- Dave Crocker Brandenburg InternetWorking bbiw.net ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Header munging, not ARC, can solve the mailing list problem
On Sun, Jun 21, 2020 at 1:32 PM Dave Crocker 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
