Re: [dmarc-ietf] DMARC alignment conflicts with RFC 5322 on the use of the From and Sender header fields
On Fri, Jun 5, 2020 at 12:40 AM Jim Fenton wrote: > On 6/2/20 10:35 AM, Dotzero wrote: > > > As part of the original DMARC team, the goal was to make clear whether the > email was authorized by the domain being used, hence the reliance on SPF > and DKIM. These are clearly under the domain owner/administrator's control > to the extent they choose to exercise that control. There was much > discussion in the community at the time to use thei= field to enable more > granular signing. it never gained traction. Because the intent was to > protect end users from fake emails purporting to be from (primarily) > commercial domains such as financial institutions, greeting card companies, > etc., the Sender field was not a significant issue. Also, when the Sender > is in the same domain as the From, there is no DMARC issue. > > > I'm all confused about why alignment matters. Back around the time DKIM > was standardized, we were concerned about phishing attacks from look-alike > domains, i.e., substitutions of 1 for l, that might be registered by > attackers and sign their messages with valid DKIM signatures. > > But now a lot of people don't see anything but the Friendly Name; the > email address isn't displayed at all. For that (apparently increasing) > proportion of users, the From or Sender addresses aren't visible; the > attacker might as well use any Friendly Name of their choosing with any > domain they can sign for there. So they get DMARC alignment, but what has > it accomplished? > > -Jim > The goal of DMARC was (and is) to mitigate direct domain abuse. Nothing more and nothing less. It helps receiving systems identify a (correctly) participating domain's mail. That is why a DMARC policy is often described as a sending domain's request and local policy is so important (and can override that request). For attackers that deploy DMARC it simply means that they are self identifying their malicious messages as theirs. Much has incorrectly been attributed to SPF/DKIM/DMARC. For example: "It stops spam" - It does not. "It stops phishing" - It does not. The modest goal is to stop direct domain abuse. It can do this remarkably well. On the other hand it creates an incentive for attackers to compromise participating domains. This has led to the long standing discussion (more lately lapsed) between Dave Crocker and my self about reputation. My position is that long term, reputation systems are of limited value because of domain compromise or even sending policy change. To put it another way, "What have you done to me today?". Dave has in the past had greater faith in reputation. For Sending domains, SPF/DKIM/DMARC is only one set of tools in protecting their brand from abuse. It protects end users from abuse. In fact, in many cases the individuals most susceptible to falling prey to such abuse may not even be customers of that sending domain. No, that greeting card you received isn't legit (Nobody loves you). No, that retailer isn't giving you a $200 gift card. This is why other tools like takedowns are so important and why the removal of registrant information from domain registrations has enabled abusers. Just a few thoughts. Michael Hammeer ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] DMARC alignment conflicts with RFC 5322 on the use of the From and Sender header fields
On 6/2/20 10:35 AM, Dotzero wrote: > > As part of the original DMARC team, the goal was to make clear whether > the email was authorized by the domain being used, hence the reliance > on SPF and DKIM. These are clearly under the domain > owner/administrator's control to the extent they choose to exercise > that control. There was much discussion in the community at the time > to use thei= field to enable more granular signing. it never gained > traction. Because the intent was to protect end users from fake emails > purporting to be from (primarily) commercial domains such as financial > institutions, greeting card companies, etc., the Sender field was not > a significant issue. Also, when the Sender is in the same domain as > the From, there is no DMARC issue. I'm all confused about why alignment matters. Back around the time DKIM was standardized, we were concerned about phishing attacks from look-alike domains, i.e., substitutions of 1 for l, that might be registered by attackers and sign their messages with valid DKIM signatures. But now a lot of people don't see anything but the Friendly Name; the email address isn't displayed at all. For that (apparently increasing) proportion of users, the From or Sender addresses aren't visible; the attacker might as well use any Friendly Name of their choosing with any domain they can sign for there. So they get DMARC alignment, but what has it accomplished? -Jim ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Reminder - DMARC Interim 11 June 2020
We are also looking for someone to take minutes and someone to assist monitoring the Jabber room For minutes, we'll try to use the Etherpad (link in the Agenda) but minute taker is not bound by that. Thanks tim On Thu, Jun 4, 2020 at 8:32 PM Tim Wicinski wrote: > > All > > Reminder that the DMARC Interim will happen next Thursday 11 June 2020. > This will be after a M3AAWG session on DMARC 2.0. The main agenda will be > bringing forward discussion items from the M3AAWG session. > > The IETF portion will be under IETF rules, with the appropriate IETF Note > Well (https://ietf.org/about/note-well/) > > Date: 14 April 2020 > Time: 1400-1600 UTC > Webex: > https://ietf.webex.com/ietf/j.php?MTID=m706bba8b48e3db3db02d72f0941b2630 > > Alexey/Seth/Tim > ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
[dmarc-ietf] Reminder - DMARC Interim 11 June 2020
BEGIN:VCALENDAR VERSION:2.0 METHOD:PUBLISH PRODID:-//IETF//datatracker.ietf.org ical agenda//EN BEGIN:VEVENT UID:ietf-interim-2020-dmarc-01-12834-dmarc SUMMARY:dmarc - Domain-based Message Authentication, Reporting & Conformance LOCATION:None STATUS:CONFIRMED CLASS:PUBLIC DTSTART;TZID="UTC":20200611T16 DTEND;TZID="UTC":20200611T17 DTSTAMP:20200510T124745Z URL:https://datatracker.ietf.org/meeting/interim-2020-dmarc-01/materials/agenda-interim-2020-dmarc-01-dmarc-01 DESCRIPTION:\n \nAgenda: https://datatracker.ietf.org/meeting/interim-2020-dmarc-01/materials/agenda-interim-2020-dmarc-01-dmarc-01\n END:VEVENT END:VCALENDAR BEGIN:VCALENDAR VERSION:2.0 METHOD:PUBLISH PRODID:-//IETF//datatracker.ietf.org ical agenda//EN BEGIN:VEVENT UID:ietf-interim-2020-dmarc-01-12834-dmarc SUMMARY:dmarc - Domain-based Message Authentication, Reporting & Conformance LOCATION:None STATUS:CONFIRMED CLASS:PUBLIC DTSTART;TZID="UTC":20200611T16 DTEND;TZID="UTC":20200611T17 DTSTAMP:20200510T124745Z URL:https://datatracker.ietf.org/meeting/interim-2020-dmarc-01/materials/agenda-interim-2020-dmarc-01-dmarc-01 DESCRIPTION:\n \nAgenda: https://datatracker.ietf.org/meeting/interim-2020-dmarc-01/materials/agenda-interim-2020-dmarc-01-dmarc-01\n END:VEVENT END:VCALENDAR ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] DMARC alignment conflicts with RFC 5322 on the use of the From and Sender header fields
In article <652580c1-5f8b-4d11-af25-d968b277c...@www.fastmail.com>, Stan Kalisch wrote: >> That depends on who creates the Author: field. I'd imagine it can be created >> on rewriting From:. If it exists already at that time, one can still check >> (by >> ARC?) if it was signed, and, in case, sign it in turn. > >I, too, was wondering whether ARC was really the only practical way to attempt >this, assuming you >don't think it deviates enough from ARC's purpose. It took me a while to understand why ARC works the way it does but now that I do, I don't think anything simpler would do. In particular, anything that lets you say "I'm a mailing list" is out since spammers can do that too. Also, real mailing lists tend to have lousy spam filtering and leak a lot of spam, so you can't just whitelist everything from even real lists. -- Regards, John Levine, jo...@taugh.com, Primary Perpetrator of "The Internet for Dummies", Please consider the environment before reading this e-mail. https://jl.ly ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] DMARC alignment conflicts with RFC 5322 on the use of the From and Sender header fields
On Wed, Jun 3, 2020, at 2:30 PM, Alessandro Vesely wrote: > On Wed 03/Jun/2020 19:27:52 +0200 Dave Crocker wrote: > > On 6/3/2020 10:20 AM, Alessandro Vesely wrote: > >> On Wed 03/Jun/2020 18:43:16 +0200 Dave Crocker wrote: > >>> On 6/3/2020 9:38 AM, Alessandro Vesely wrote: > MUAs should be discouraged from displaying or using Author:, unless > (verifiably) signed by a trusted domain or otherwise configured by the > user. > >>> Why? > >> That avoids the dreaded back-to-square-one path that Brandon conjectured. > >> It > >> prevents attacks based on this field, while maintaining the DMARC paradigm. > > > > The barrier you specified sounds reasonable. But it isn't. > > > > Any signature put in place when the Author: field is created is likely > > broken > > by the time it gets to the recipient. That's the entire problem that > > necessitates rewriting the From: field. > > > That depends on who creates the Author: field. I'd imagine it can be created > on rewriting From:. If it exists already at that time, one can still check > (by > ARC?) if it was signed, and, in case, sign it in turn. I, too, was wondering whether ARC was really the only practical way to attempt this, assuming you don't think it deviates enough from ARC's purpose. Thanks, Stan ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] DMARC alignment conflicts with RFC 5322 on the use of the From and Sender header fields D
MAILING LISTS. The mailing list problem can be stated as follows: Domain B wants to operate a mailing list.The list owner will accept messages from domain A, alter them, then re-transmit the altered message to member C.List owner B wants the mail filter for member C to guarantee that his list messages are granted the same trust level as a message sent directly from A to C without alteration. This problem is unsolvable because it is unreasonable. The options for creating trust in indirect mail have been discussed in another RFC. Applied to this issue, the options are: 1) Make List B the originator by changing the RFC 5321 sender address as well as the RFC 5322 Message From. Ideally add a DKIM signature for B, in case the message is forwarded downstream. This is the IETF list behavior and the only one that is feasible in practice. .. 2) Require all submitting domains to make List B a trusted sender for their domain by including B in their SPF record 3) Configure the list to make no changes, then require all senders to include DKIM signatures for their own domain. 4) Require all recipient systems to make special policy accommodations to grant trust to messages from List B, simply because it comes from List B. This is feasible, but specific to each participants incoming email filter. DKIM and IDENTIFIERS A large portion of legitimate mail is generated by third parties acting as agents. The problem being addressed by SPF / DKIM / DMARC is: "How can a sender provide information so that a recipient can distinguish between an authorized agent and an unauthorized identity thief?" A subset of this issue is "How do we expect recipient systems to behave?" This is a rather important detail which this group has explicitly chosen to not pursue. But I can provide these observations based on experience with mail filtering: To avoid false positives on desired messages, messages from some senders must be given some filtering exceptions. For those exceptions to be applied safely, the sender must be verified to a degree acceptable to the recipient. Depending on the situation, there are multiple ways that a sender can be identified. These include, but are not limited to, SPF, DKIM, and DMARC.. In the general case, SPF, DKIM, and DMARC simplify this problem for the recipient. Although SPF, DKIM, and DMARC are often assumed to be tools for discarding fraudulent messages, this is extraordinarily difficult to implement in practice. Too many senders have errors in their SPF / DKIM / DMARC configurations, and too many legitimate senders do things that violate a domain owner's SPF / DKIM / DMARC policies. Policy failure has not proven to be a reliable indicator of unwanted content. Without DMARC, SPF and DKIM configuration errors persist because the sender obtains no feedback about those errors. DMARC fixes the feedback problem. I still do not understand how DMARC does anything other than enhance prior work on SPF and DKIM, or how there is any conflict with prior standards. Doug Foster ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
