Re: [dmarc-ietf] Is From spoofing an interoperability issue or not?
On Wed, Apr 19, 2023, at 12:35 PM, Alessandro Vesely wrote: > On Wed 19/Apr/2023 15:37:25 +0200 Laura Atkins wrote: > > To me it’s not so much the company can’t delegate authentication - it’s how > > many SaaS providers (some of which are ESPs and some of which are 3rd > > parties > > that send through ESPs) are incapable of supporting DMARC alignment. Not > > it’s > > hard, not it’s challenging, but simply … can’t. They cannot sign with > > foreign > > DKIM domains, and they cannot support different domains for SPF > > authentication. > > > > Should DMARCbis make the recommendation that if you are providing mail > > services > > that you SHOULD be able to support corporate customers using DMARC? > > > IMHO at least an appendix should say that if you can't do anything better you > have to rewrite From: with examples of legitimate display-phrase, expanding a > bit the first bullet in Section 11.4. That can also be a good place to > explain > the kind of damage DMARC causes. That's what I'm getting at. I don't really see any difference between a mailing list and someone providing mail services (I won't use the word ESP since that seems to be a loaded term) for corporate customers (I would also add government customers, who are adhering to BOD 18-01 in droves and they are also adopting said companies providing mail services) The choice for both the mailing list and mail-service company is to: 1) ignore DMARC and continue to emit mail as the original author intended (the author might be ignorant of DMARC too) and assume the mailbox providers are smart enough to understand that, like mailing lists, mail-service companies and their mail emitting authors shouldn't be caught up by a DMARC misdeployment by the domain owner 2) be cognisant of DMARC's effects, and in the interest of keeping the author's mail flowing, use a different domain and put the author's address in the friendly from or similar, or just refuse to accept the messages, until delegation can be set up. I can say, anecdotally, that people really really want #1 to be true, but they eventually learn #2 leads to a better long term outcome. I'd like that "learning" to be less painful by having something unambiguous to point at in DMARCbis. Jesse___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Is From spoofing an interoperability issue or not?
On Wed 19/Apr/2023 15:37:25 +0200 Laura Atkins wrote: To me it’s not so much the company can’t delegate authentication - it’s how many SaaS providers (some of which are ESPs and some of which are 3rd parties that send through ESPs) are incapable of supporting DMARC alignment. Not it’s hard, not it’s challenging, but simply … can’t. They cannot sign with foreign DKIM domains, and they cannot support different domains for SPF authentication. Should DMARCbis make the recommendation that if you are providing mail services that you SHOULD be able to support corporate customers using DMARC? IMHO at least an appendix should say that if you can't do anything better you have to rewrite From: with examples of legitimate display-phrase, expanding a bit the first bullet in Section 11.4. That can also be a good place to explain the kind of damage DMARC causes. Best Ale -- ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Signaling MLMs
On Wed 19/Apr/2023 15:50:54 +0200 Benny Pedersen wrote: Alessandro Vesely skrev den 2023-04-19 11:09: if all maillist did arc on incoming mails before mailman scraped dkim then all will be good, only left is dmarc is not in all places tests arc results It is all too easy to spoof an ARC chain offering false authentication results. ARC chains is untrusted by default, where is the problem ? Just pointing out that "if all maillist did arc on incoming mails before mailman scraped dkim" then that is not enough. Allowing ARC to override DMARC result requires the ARC signer to be whitelisted. whitelisted is not right word for it, its either trusted or untrusted Yes, I meant to say a site can make a list of all the ARC-sealers they trust and call it a whitelist. Now, one can object that whitelisting could be done by DKIM, by SPF, by DNSWL, without the need to introduce a new, long-winded protocol. However, ARC brings a couple of advantages: 1) In case of multiple forwarding steps, ARC delivers an ordered and cohesive chain which is easier to verify than a messy mass of DKIM signatures. recipients should only care of dmarc, not dkim/arc/spf fails to make this work dmarc must trust arc Here a lost you. DMARC is a protocol. It cannot give credence or believe. It can pass or fail. It is receivers who can trust an ARC chain and override DMARC results; that is, allow the message even if dmarc=fail and p=reject. Best Ale -- ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Is From spoofing an interoperability issue or not?
It appears that Laura Atkins said: >That was my question: is it an interop issue that ESPs (whether they be your >traditional ESP or a SaaS provider that sends >mail on behalf of their customers) cannot support custom domains in the SPF >and DKIM and thus cannot support DMARC? Many of >the current companies have made the decision that supporting DMARC is too >hard, and so what they do is use their own domain >for DMARC (some publish restrictive polices and some don’t). I don't see how it's an interop problem. They send mail, recipients do the usual DMARC thing with it. The choice of identity may be a business problem between them and their customers, but that's not up to us. I can easily imagine situations where a company figures it's not a particularly attractive phish target, they balance the possible cost of misleading email against the cost of implementing delegated DKIM or subdomains or whatever and decide just go ahead and send. >Should DMARCbis make the recommendation that if you are providing mail >services that you SHOULD be able to support corporate >customers using DMARC? It seems to me purely a business decision what domain you use on your mail, so long as it's not one you're not allowed to use. While I agree with you that it is not great that ESPs punt on DMARC, please see once again my note about trying to enumerate all the dumb stuff people might do. R's, John ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Is From spoofing an interoperability issue or not?
On April 19, 2023 1:37:25 PM UTC, Laura Atkins wrote: > > >> On 19 Apr 2023, at 14:20, John Levine wrote: >> >> It appears that Jesse Thompson said: >>> -=-=-=-=-=- >>> >>> On Mon, Apr 17, 2023, at 8:37 AM, Laura Atkins wrote: Should the IETF make the interoperability recommendation that SaaS providers who send mail on behalf of companies support >>> aligned authentication? That means custom SPF domains and custom DKIM >>> signatures. And if they can’t, then do we make a different recommendation regarding spoofed mail that evades a company’s DMARC policy? >>> >>> +1 to this question. It's entirely unclear to ESPs whether they're allowed >>> to spoof a domain that has no DMARC policy. ESPs >>> can furthermore conclude that Domain Owners who publish p=reject|quarantine >>> are violating DMARCbis, and subsequentlly the >>> domain's policy declaration is invalid, and can be ignored. >> >> Please see my previous comment about trying to enumerate every dumb thing >> people might do. >> >> I very strenuously do not want us trying to guess how ESPs think nor >> offering them advice beyond >> the interop advice we offer everyone else. > >That was my question: is it an interop issue that ESPs (whether they be your >traditional ESP or a SaaS provider that sends mail on behalf of their >customers) cannot support custom domains in the SPF and DKIM and thus cannot >support DMARC? Many of the current companies have made the decision that >supporting DMARC is too hard, and so what they do is use their own domain for >DMARC (some publish restrictive polices and some don’t). > >> In this specific case, if the company publishes p=reject, and they hire an >> ESP, and the company >> is too inept to figure out how to let the ESP send aligned mail, well, yeah, >> then the company's >> actual policy is clearly not their published policy, and the ESP can do >> whatever it wants. So >> let's not go there. > > >To me it’s not so much the company can’t delegate authentication - it’s how >many SaaS providers (some of which are ESPs and some of which are 3rd parties >that send through ESPs) are incapable of supporting DMARC alignment. Not it’s >hard, not it’s challenging, but simply … can’t. They cannot sign with foreign >DKIM domains, and they cannot support different domains for SPF >authentication. > >Should DMARCbis make the recommendation that if you are providing mail >services that you SHOULD be able to support corporate customers using DMARC? > No. I don't think so, certainly not in DMARCbis. There may be room for an email authentication BCP and this might fit in there, but I think that's something to think about after we get the current work done. The current DKIM working group topic might also be something that should be addressed in such a BCP. Scott K ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Signaling MLMs
Alessandro Vesely skrev den 2023-04-19 11:09: Benny is telling the world “ietf.org [1] is authorize to resign on my behalf” via DNS. No headers required. No delayed learning necessary. How would I get a clue of that? reading books ? if all maillist did arc on incomming mails before mailman scrapled dkim then all will be good, only left is dmarc is not in all places tests arc results It is all too easy to spoof an ARC chain offering false authentication results. ARC chains is untrusted by defaullt, where is the problem ? Allowing ARC to override DMARC result requires the ARC signer to be whitelisted. whitelisted is not right word for it, its either trusted or untrusted Now, one can object that whitelisting could be done by DKIM, by SPF, by DNSWL, without the need to introduce a new, long-winded protocol. However, ARC brings a couple of advantages: 1) In case of multiple forwarding steps, ARC delivers an ordered and cohesive chain which is easier to verify than a messy mass of DKIM signatures. recipients should only care of dmarc, not dkim/arc/spf fails to make this work dmarc must trust arc 2) Authentication results, which normally are deleted or renamed on crossing ADMD barriers, can be exported. well it scramples dkim, no go As they can sometimes be checked against message transformation, fraudsters can in the long run be debunked. if we keep the problem on maillist we lost all the goods dkim protect, i dont want this i still wonder what errors done in rspamd now :/ my dmarc policy is none, but rspamd says its reject, hmm ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Is From spoofing an interoperability issue or not?
> On 19 Apr 2023, at 14:20, John Levine wrote: > > It appears that Jesse Thompson said: >> -=-=-=-=-=- >> >> On Mon, Apr 17, 2023, at 8:37 AM, Laura Atkins wrote: >>> Should the IETF make the interoperability recommendation that SaaS >>> providers who send mail on behalf of companies support >> aligned authentication? That means custom SPF domains and custom DKIM >> signatures. >>> >>> And if they can’t, then do we make a different recommendation regarding >>> spoofed mail that evades a company’s DMARC policy? >> >> +1 to this question. It's entirely unclear to ESPs whether they're allowed >> to spoof a domain that has no DMARC policy. ESPs >> can furthermore conclude that Domain Owners who publish p=reject|quarantine >> are violating DMARCbis, and subsequentlly the >> domain's policy declaration is invalid, and can be ignored. > > Please see my previous comment about trying to enumerate every dumb thing > people might do. > > I very strenuously do not want us trying to guess how ESPs think nor offering > them advice beyond > the interop advice we offer everyone else. That was my question: is it an interop issue that ESPs (whether they be your traditional ESP or a SaaS provider that sends mail on behalf of their customers) cannot support custom domains in the SPF and DKIM and thus cannot support DMARC? Many of the current companies have made the decision that supporting DMARC is too hard, and so what they do is use their own domain for DMARC (some publish restrictive polices and some don’t). > In this specific case, if the company publishes p=reject, and they hire an > ESP, and the company > is too inept to figure out how to let the ESP send aligned mail, well, yeah, > then the company's > actual policy is clearly not their published policy, and the ESP can do > whatever it wants. So > let's not go there. To me it’s not so much the company can’t delegate authentication - it’s how many SaaS providers (some of which are ESPs and some of which are 3rd parties that send through ESPs) are incapable of supporting DMARC alignment. Not it’s hard, not it’s challenging, but simply … can’t. They cannot sign with foreign DKIM domains, and they cannot support different domains for SPF authentication. Should DMARCbis make the recommendation that if you are providing mail services that you SHOULD be able to support corporate customers using DMARC? laura -- The Delivery Experts Laura Atkins Word to the Wise la...@wordtothewise.com Email Delivery Blog: http://wordtothewise.com/blog ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Is From spoofing an interoperability issue or not?
It appears that Jesse Thompson said: >-=-=-=-=-=- > >On Mon, Apr 17, 2023, at 8:37 AM, Laura Atkins wrote: >> Should the IETF make the interoperability recommendation that SaaS providers >> who send mail on behalf of companies support >aligned authentication? That means custom SPF domains and custom DKIM >signatures. >> >> And if they can’t, then do we make a different recommendation regarding >> spoofed mail that evades a company’s DMARC policy? > >+1 to this question. It's entirely unclear to ESPs whether they're allowed to >spoof a domain that has no DMARC policy. ESPs >can furthermore conclude that Domain Owners who publish p=reject|quarantine >are violating DMARCbis, and subsequentlly the >domain's policy declaration is invalid, and can be ignored. Please see my previous comment about trying to enumerate every dumb thing people might do. I very strenuously do not want us trying to guess how ESPs think nor offering them advice beyond the interop advice we offer everyone else. In this specific case, if the company publishes p=reject, and they hire an ESP, and the company is too inept to figure out how to let the ESP send aligned mail, well, yeah, then the company's actual policy is clearly not their published policy, and the ESP can do whatever it wants. So let's not go there. R's, John ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] DSAP "DKIM Sender Authorization Protocol" for DMARC
Hector, does your proposal allow for constrained delegation? I think we have a problem if this type of third-party signing allows any account at the list domain to impersonate any account in any participating domain. DF On Sat, Apr 8, 2023, 2:01 PM Hector Santos wrote: > Summary: > > I would like to reintroduce the DSAP (DKIM Sender Authorization Protocol) > as a DMARC extended tag extension -dsap. The original DSAP draft covered > nine 1st vs 3rd party signature policies from a verifier viewpoint, which > addressed boundary conditions for DKIM signatures. The reintroduction aims > to address concerns regarding 3rd party resigners. > > Key changes proposed for DMARC integration: > > o Introduce -dsap tag for DSAP support, covering a complete range of > possible policies. > > o Use -asl tag for inline list of authorized signer support. > > o Implement -atps tag for ATPS support. > > o Formalize the From rewrite logic with a -rewrite tag. > > o Introduce -target tag to assist mail forwarders with authorized > redirection of exclusive policies. > > The proposal seeks to offer better integration with today's wide range of > mail applications, building on the existing DMARC protocol and improving > 3rd party authorization and reporting. > > > Background: > > In 2006, I submitted an I-D DSAP “DKIM Sender Authorization Protocol” that > covers the boundary conditions for 1st vs 3rd party signature > expectations. There are nine 1st vs 3rd party signature policies in DSAP > from a verifier viewpoint: > > Original 1st Party Signature (OPS) > Not expected (-) > Expected (+) > Optional (~) > > Third Party Signature (3PS) > Not expected (-) > Expected (+) > Optional (~) > > Using these expectations, DSAP can cover most if not all possible Boundary > Conditions for DKIM signatures. > > I would like to re-propose DSAP but this time as a DMARC extended tag > extension `-dsap` as I believe it can address our concerns regarding 3rd > party resigners. > > Here is the 2006 DSAP proposal I plan on updating to support DMARC and > ATPS: > > https://datatracker.ietf.org/doc/html/draft-santos-dkim-dsap-00 > > History: > > The DKIM Policy Model began with SSP “Sender Signature Practices/Policy.” > This image illustrates the overall process: > > > [image: SSP Overview] > > Many today do not realize the original DKIM included Signature Policy > protocol called SSP. It was spit into DKIM-BASE and DKIM-SSP to help > speed up the process. DKIM was well defined but SSP was not. SSP covered > various signing scenarios, however, there were 3 policies missing which > DSAP covered: > > [image: v3_slide0022_image050.gif (392×199)] > > The DMARC protocol offers an exclusive only policy with > p=reject|quarantine. This would be a -dsa=OP+,3P- policy With DMARC p=none, > no other policy possible in terms of expectation other than an unhandled > failed exclusive policy. So DMARC is very limited making it a very to > integrate with today’s wide range of mail applications. > > DMARC also introduced two more takes that I would like use replaced with > DMARC and ATPS. > > For Reporting, DSAP provides tags for failure reports. This is now > well-defined with DMARC. [DSAP only considered failure reports]. > > For 3rd party authorization, DSAP provided the -asl tag. The asl tag was > an inline small domain list tag. But it can also signify a check using > ATPS for higher scale applications. > > Everything would be the same with DMARC and DMARCbis. The change would > be: > > -dsap tag for DSAP support for the complete range of possible policies. > > -asl for inline list of authorize signer support > > -atps for ATPS support > > I would also like to formalize the From rewrite logic with a tag: > > -rewrite > > Which tells a resigner it may rewrite the From under certain conditions. > > -target is a new tag to help mail forwarders. > > DMARC has considerations for SPF results with a strong alignment > requirement. One scenario where a -dsap=op+,3p- is with SPF hard failure > during mail forwarding. The -target will allow a forwarder to resign as a > 3rd party without -asl or -atps requirements. > > — > Hector Santos, CEO/CTO > Santronics Software, Inc, > ___ > dmarc mailing list > dmarc@ietf.org > https://www.ietf.org/mailman/listinfo/dmarc > ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Signaling MLMs
On Wed 19/Apr/2023 01:13:48 +0200 Benny Pedersen wrote: Hector Santos skrev den 2023-04-18 20:47: So your verifier see Benny’s as suspicious because of arc=fail? it does imho not fail on my own arc ? My filter attempts to recover DKIM signatures after MLM transformation, but not ARC chains. Currently, ARC is evaluated but its result don't modify message worthiness. Benny is telling the world “ietf.org [1] is authorize to resign on my behalf” via DNS. No headers required. No delayed learning necessary. How would I get a clue of that? if all maillist did arc on incomming mails before mailman scrapled dkim then all will be good, only left is dmarc is not in all places tests arc results It is all too easy to spoof an ARC chain offering false authentication results. Allowing ARC to override DMARC result requires the ARC signer to be whitelisted. Now, one can object that whitelisting could be done by DKIM, by SPF, by DNSWL, without the need to introduce a new, long-winded protocol. However, ARC brings a couple of advantages: 1) In case of multiple forwarding steps, ARC delivers an ordered and cohesive chain which is easier to verify than a messy mass of DKIM signatures. 2) Authentication results, which normally are deleted or renamed on crossing ADMD barriers, can be exported. As they can sometimes be checked against message transformation, fraudsters can in the long run be debunked. Best Ale -- ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
