Re: [dmarc-ietf] DMARC-Compliant Mailing Lists
Creating a DMARC record on your domain means (among other things) that you expect no email sent from your domain to be a contribution to mailing list discussions. Telling mailing list owners and mailing list software designers to violate RFC 5322 Internet message format's description of the From header line to make you happy is abusive. How does your decision to implement DMARC become their problem? That is not right. Your choice is not their problem. The DMARC standard should say, implement this only for domains that will send mail that should never be forwarded or sent to mailing lists. That was the original purpose. It does very well for that use case and it is very valuable for that use case. All of the problems come from misusing DMARC for ordinary end-user email. I'm talking to you, yahoo. I got tired of posting here, but that is still my position. Joe Brennan Columbia University IT ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Doing a tree walk rather than PSL lookup
I will ask why the recipient system should look up anything but the dmarc record for the specific domain in the Header From. In some cases looking up related domains is useful, and in some cases it can lead to disruption. We don't look up SPF records for related domains, because they are deliberately different in many cases, e.g. one domain for mail from end users, another for mail sent by a vendor, yet another for another vendor. Why is dmarc different? -- Joseph Brennan Lead, Email and Systems Applications Columbia University Information Technology ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] ARC questions
> > > > > On Sat, Nov 21, 2020 at 7:14 PM John Levine wrote: > >> >> > This also means that ARC isn't useful if you don't have a reputation >> system to tell you where the lists and other forwarders that might add >> legit ARC signatures are. >> > > And if you know which hosts are legit mailing lists or forwarders, you already know what ARC would tell you. -- Joseph Brennan Lead, Email and Systems Applications Columbia University Information Technology ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Organizational domains, threat or menage, was On splitting documents and DBOUND
> >> As another case, would people be surprised that email for the medical >> center cumc.columbia.edu is a separate system managed by a separate IT >> group from columbia.edu, and that any authentication for one should not >> be applied to the other? I don't think this is unique in large >> decentralized universities. The real email world is a complicated place. >> >> > The simple solution is for cumc.columbia.eduto publish its own record. > Done. > > Michael Hammer > I don't think I have the right to force the owner of another domain to publish dmarc. The owner of the other domain may want to allow users in their domain to contribute to lists and groups without having their messages rejected, or mangled by well-intentioned workarounds. This is not simple. This is a real-world case with the domains ending columbia.edu. -- Joseph Brennan Lead, Email and Systems Applications Columbia University Information Technology ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Organizational domains, threat or menage, was On splitting documents and DBOUND
On Wed, Nov 11, 2020 at 4:21 PM Dave Crocker wrote: > > Just to invoke a bit of ancient history, here, you are saying that if > there was the domain name: > > engineering.sun.com > > people would be surprised that the organization domain is > > oracle.com > > As another case, would people be surprised that email for the medical center cumc.columbia.edu is a separate system managed by a separate IT group from columbia.edu, and that any authentication for one should not be applied to the other? I don't think this is unique in large decentralized universities. The real email world is a complicated place. -- Joseph Brennan Lead, Email and Systems Applications Columbia University Information Technology ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] DMARC as Signal to MLMs for Rewrites (or not)
or don't use p=quarantine and p=rejectKeep it simple On Fri, Sep 18, 2020 at 5:47 AM Alessandro Vesely wrote: > On Thu 17/Sep/2020 21:11:42 +0200 Sabahattin Gucukoglu wrote: > > > > Wouldn’t it be nice if you could ask for MLMs to transform, just using a > DMARC policy, even p=none, so that you could test with a live environment > containing MLMs that work around DMARC policy? Or you could ask for *no* > transform, even for p=quarantine or p=reject, so that your DMARC policy can > be used to legitimately restrict usage to directly-sent email? > > > It may be practical to place the asking in the message header, rather than > in the DMARC record. That way, senders can specify their wish on a > per-message basis, presumably based on message recipients. Note that a > request to transform can include information about how to reliably undo the > transformation, thereby verifying the original DKIM signature as described > in dkim-transform[*]. Possible strategies that senders might use could be > similar to those for putting weak signatures[†]. > > > Best > Ale > -- > [*] https://tools.ietf.org/html/draft-kucherawy-dkim-transform > [†] > https://tools.ietf.org/html/draft-levine-dkim-conditional-04#section-4.1 > > > > > > > > > > > > > > > > > > > > > > > > > ___ > dmarc mailing list > dmarc@ietf.org > https://www.ietf.org/mailman/listinfo/dmarc > -- Joseph Brennan Lead, Email and Systems Applications Columbia University Information Technology ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Issue submission - Mailing list security and potential solutions using DMARC
What I mean is that mailing list software developers were obliged to find a variety of ways to evade dmarc enforcement, for the sake of delivering legitimate mail, and mailbox server developers learned to allow mangled mail for the same reason. Widespread acceptance of email that evades an authentication method diminishes its effectiveness. On Wed, Sep 16, 2020 at 10:46 AM Dotzero wrote: > > > > On Tue, Sep 15, 2020 at 12:02 PM Joseph Brennan wrote: >> >> >> >> On Tue, Sep 15, 2020 at 11:55 AM John Levine wrote: >>> >>> In article >>> , >>> Joseph Brennan wrote: >>> >"Domain administrators must not apply dmarc authentication to domains >>> >from which end users send mail that may be re-sent via lists or >>> >automatic forwarding." -- done. Then dmarc will be simple and >>> >reliable, and bank statements and similar messages are protected as >>> >intended. Building in a standard workaround significantly weakens the >>> >whole concept, doesn't it? >>> >>> Unfortunately, we have ample evidence that domain operators will >>> ignore that advice. >>> >>> According to someone who was in the room when Yahoo flipped the >>> switch, the person in charge said words to the effect that I know this >>> will screw up everyone's mailing lists and I don't care. >>> >> >> The irony is, the result being to diminish the effectiveness of dmarc for >> everybody. >> >> >> Joseph Brennan >> Lead, Email and Systems Applications >> Columbia University Information Technology >> >> > > Can you support your assertion with data? There was zero change > post-yahoo/AOL implementation vs pre-yahoo/AOL implementation for the > organization I worked for at the time. > > Michael Hammer -- Joseph Brennan Lead, Email and Systems Applications Columbia University Information Technology ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Issue submission - Mailing list security and potential solutions using DMARC
On Tue, Sep 15, 2020 at 11:55 AM John Levine wrote: > In article bnk2_ckmn...@mail.gmail.com>, > Joseph Brennan wrote: > >"Domain administrators must not apply dmarc authentication to domains > >from which end users send mail that may be re-sent via lists or > >automatic forwarding." -- done. Then dmarc will be simple and > >reliable, and bank statements and similar messages are protected as > >intended. Building in a standard workaround significantly weakens the > >whole concept, doesn't it? > > Unfortunately, we have ample evidence that domain operators will > ignore that advice. > > According to someone who was in the room when Yahoo flipped the > switch, the person in charge said words to the effect that I know this > will screw up everyone's mailing lists and I don't care. > > The irony is, the result being to diminish the effectiveness of dmarc for everybody. Joseph Brennan Lead, Email and Systems Applications Columbia University Information Technology ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Issue submission - Mailing list security and potential solutions using DMARC
It must be unusual for an authentication protocol to specify in the RFC how to work around its own authentication mechanism. "Domain administrators must not apply dmarc authentication to domains from which end users send mail that may be re-sent via lists or automatic forwarding." -- done. Then dmarc will be simple and reliable, and bank statements and similar messages are protected as intended. Building in a standard workaround significantly weakens the whole concept, doesn't it? -- Joseph Brennan Lead, Email and Systems Applications Columbia University Information Technology ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Call for Adoption: DMARC Use of the RFC5322.Sender Header Field
On Mon, Aug 17, 2020 at 6:24 AM Laura Atkins wrote: > > > The DMARC proponents have asserted that DMARC prevents domain specific > spoofing and phishing. The amount of harm DMARC authentication has caused, > however, seems disproportional to this small benefit. Phishing is still > happening using cousin domains (and even random domains). Departments > inside companies avoid DMARC mandates buy buying cousin and “campaign > specific” domains which trains users to be phishing targets for those > domains. Companies have tried to cut down on this by saying DMARC must be > done for all those domains as well. Unfortunately, those “from above” > decrees have often created more problems than they solved. > > Mailing lists have coped by rewriting from addresses, but that has caused > a lot of issues. Two of the big ones are members can no longer search for > “mail from this list member” and cannot easily create filters acting on > mail from other participants. > Well said (I liked the poetic indentation too) The fact is that DMARC has disrupted the flow of ordinary legitimate email. Actors not involved or interested in DMARC have had to spend time and money developing ways to work around DMARC in order to keep mailing lists and forwarding working, or else they have had to spend time and money on the alternative of informing their customers that legitimate practices they have done for years no longer work reliably and have to be discontinued. Adding more complexity does not make a broken thing less broken. I think the proposed standard should simply spell out in plain words that the purpose of DMARC is to protect transactional mail, e.g. about bank and credit accounts or purchase confirmations, and that it is not for mail from ordinary end users. Given that I think more sending systems would be willing to publish p=reject and more receiving systems would be willing to honor it. It won't be the end of spoofs, but it would reduce the disruption to people outside the DMARC club. --- Joseph Brennan ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Fwd: New Version Notification for draft-crocker-dmarc-sender-01.txt
> On 7/27/2020 11:14 AM, Alessandro Vesely wrote: > > > Let's say I have From: real.bank, and Sender: phisher.example. The > > above text seems to imply the receiver is looking up > > _dmarc.phisher.example. Correct? > Avoiding it by redefining From: to serve the former purpose of Sender: and creating a new Author: to serve the former purpose of From: seems to me to start us down a long road of new header fields every couple of years. They are just names. Verifying that the message really is from phisher.example is a useful data point. The receiving system can choose to mark it with a warning like "you never had mail before from phisher.example". Consider a DMARC DNS tag for the bank to ask the receiving system to verify the From, while the end-user system would not use that tag. I think this is the distinction that should be made, for mailing lists to work but sensitive data to be more protected than end-user mail. -- Joseph Brennan Lead, Email and Systems Applications Columbia University Information Technology ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Why are MUAs hiding or removing the From address?
On Thu, Jul 23, 2020 at 9:20 AM Benny Pedersen
wrote:
> show the source on how to make this work in mimedefang, or will it
> completely fail with spampd ?
Since it is off topic, I will give a short answer. If the Header From
matches /From: anything , check whether domain is one
that needs the rewrite, gmail.com for example, and change the field to
be simply /From: string@domain/.
In Mimedefang, we created a per-message global hash %Header, and
parsed each field (split on :). So for example $Header{from} was the
value of the From header field. The hash was used in various rules. MD
has a built-in function to replace the content of header fields, which
I think is a milter function.
--
Joseph Brennan
Lead, Email and Systems Applications
___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Why are MUAs hiding or removing the From address?
On Tue, Jul 21, 2020 at 5:45 PM Jesse Thompson wrote: > > Specifically to address BEC we strip the friendly from (at our MTA gateways > prior to ingestion to O365) conditionally (one example: from domains of free > email providers) to force the MUA (Outlook and everything else) to show the > From address. > > It works because now the victims just see "wisc.edu.provos...@gmail.com" > instead of "Office of the Provost" and are more likely to consider the > message hostile, less likely to click on the weird link, less likely to buy > gift cards, and so on. > Briliant! I wish we were still using Mimedefang. This wouldn't be hard to code, and the results would be effective. -- Joseph Brennan Lead, Email and Systems Applications ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Response to a claim in draft-crocker-dmarc-author-00 security considerations
On Mon, Jul 20, 2020 at 6:05 PM Jesse Thompson wrote: > > > > It calls into question whether we (or any domain) should publish DMARC > policies. Gmail.com doesn't publish a DMARC policy, after all, and many > people (such as some on this list) are using gmail.com to subscribe to lists, > and they don't have to suffer the consequences of DMARC. I interpret Gmail's approach as a fine marketing decision. It means mail from gmail.com is more deliverable than mail from yahoo and aol. They must be smiling every time some domain rejects end-user mail for DMARC violations. > > I think that we just have to agree that From-munging by MLMs is a permanent > reality. It needs to be documented more prominently (and promoted as part of > the DMARC marketing) so that implementations are more consistent, so that > un-munging tactics and/or MUA behavior can be consistently implemented. > I'd be happier for the proposed standard to say that DMARC policy "SHOULD NOT" be compromised by rewriting From lines-- and see how that goes over. My reasoning is that blessing the practice makes it easier for bad actors to craft spoofed mail and get it accepted. The opposite of the purpose of DMARC, isn't it? -- Joseph Brennan Lead, Email and Systems Applications ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Response to a claim in draft-crocker-dmarc-author-00 security considerations
On Tue, Jul 21, 2020 at 2:08 PM Hector Santos wrote: > > Second, DMARC is imposing a new security protocol based on the premise > the "From" is not expected to be changed. How will the MLM/MLS fit? > > It can: > > 1) Supports the security protocol and the problem is solved. > Exclusive domains made a published policy statement for exclusive > signing. The Exclusive Domains does not expect its users to be using > their domains outside the work place. The policy is honored. My understanding of DMARC's purpose was to protect transactional messages from sources like banks, credit card issuers, online shopping venues, and the like. It supposed that those messages should pass only directly from the source to the end point, and that that was so important to security that transport through any intermediary should be rejected as possible forgery. For example my bank statements come from a different domain than mail from a person at the bank. What blew it away was Yahoo's implementation of DMARC on end user personal mail. It was at first believed by many that Yahoo would have to roll it back when their users could not contribute to mailing lists or send mail to people who had old-school forwarding. Instead the industry started developing ways to get around DMARC by changing RFC 822 From headers and RFC 821 MAIL commands... which pretty much un-did the DMARC concept of authorization. It has been demonstrated that #1 is not happening, and it's because sheer deliverability of legitimate email is the priority. -- Joseph Brennan Lead, Email and Systems Applications ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Why are MUAs hiding or removing the From address?
On Tue, Jul 21, 2020 at 1:28 PM Brandon Long wrote: > > Do sms/mms programs show the phone number any more? I think there's been a > deliberate strategy to make email clients more like > other messaging clients, and the technical parts like the actual address are > details that most of the time aren't useful to the user... when > they're not being spoofed, of course, or otherwise need to differentiate > between multiple addresses for the same person. > - I think you're right about how non-email messaging clients have influenced email. But even in email, Microsoft's Outlook, with its roots as an intraoffice memo client, has shown only display name as far back as I know, except when Internet mail comes in with a From header that has no display name to show. For all its quirks, Outlook is the only client I can think of that shows the content of the RFC5322 Sender header, even if it is in the peculiar "x on behalf of y" notation, which shows display name when there is one and address otherwise. But we are digressing into a proposal for an Internet Email Client standard. Joseph Brennan Lead, Email and Systems Applications ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] draft-crocker-dmarc-author-00
We already have a field for author, called From. Why add another one? "The only required header fields are the origination date field and the originator address field(s)." By this, RFC 5322 refers to the From field. I think client software developers would be inclined to ignore creating the Author field, or else to create it and populate it with the same value as the From field. Mailing list software might want to create Author and copy the value of From into it, and then insert the list address into the From, but then, they run into "In all cases, the "From:" field SHOULD NOT contain any mailbox that does not belong to the author(s) of the message." No better than where we are now, is it? -- Joseph Brennan Lead, Email and Systems Applications ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] DMARC Use of the RFC5322.Sender Header Field
> > > > 2) draft-crocker-dmarc-sender > This is an elegant solution. It puts the burden of change-- creating a Sender field in all cases, and a variant DMARC record-- on the domain owner who wants to send mail and use DMARC rules. The use of Sender complies with RFC 5322, since it is optional whether to create Sender when it is the same address as From. With this implemented, developers of mailing list software can stop figuring out which way to violate RFC 5322 in order to make mail deliverable, and developers of clients do not have to create and display a new Author field. Big win, for widespread acceptance, I would say. -- Joseph Brennan Lead, Email and Systems Applications ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
