Re: [dmarc-ietf] Signaling MLMs

[Benny Pedersen]

Hector Santos skrev den 2023-04-17 20:55:


One solution is for the junc.eu domain to add an ATPS authorization
record for ietf.org [1] to the junc.eu [2] zone:

pq6xadozsi47rluiq5yohg2hy3mvjyoo._atps  TXT ("v=atps01; d=ietf.org;")


retest


[3] https://winserver.com/public/wcDmarc


___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

Re: [dmarc-ietf] Signaling MLMs

[Benny Pedersen]

Hector Santos skrev den 2023-04-17 20:55:


Just consider your message source. The header overhead is massively
complex to read. It is really a waste on receivers.


Apr 17 22:53:28.015 [22350] dbg: authres: parsing 
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass 
(1024-bit key) header.d=isdg.net header.b="LJSFN/J6"; dkim=pass 
(1024-bit key) header.d=beta.winserver.com header.b="x/bRVx9h"
Apr 17 22:53:28.015 [22350] dbg: authres: parsing 
Authentication-Results: dkim.winserver.com; dkim=pass 
header.d=beta.winserver.com header.s=tms1 header.i=beta.winserver.com;  
dmarc=pass policy=reject author.d=isdg.net signer.d=beta.winserver.com 
(atps signer);
Apr 17 22:53:28.016 [22350] dbg: authres: skipping header, missing 
property: =reject author.d=isdg.net signer.d=beta.winserver.com (atps 
signer);

Apr 17 22:53:28.016 [22350] dbg: authres: results: dkim=pass


pq6xadozsi47rluiq5yohg2hy3mvjyoo._atps  TXT ("v=atps01; d=ietf.org;")


added and thanks if succces :)


[3] https://winserver.com/public/wcDmarc


___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

Re: [dmarc-ietf] Is From spoofing an interoperability issue or not?

[Dotzero]

On Mon, Apr 17, 2023 at 12:05 PM John Levine  wrote:

> It appears that Laura Atkins   said:
> >Is this another issue we should document and make recommendations about?
> I was thinking along the line that transactional SaaS
> >providers should fully support DMARC and should not allow companies using
> p=reject in their business mail to access the
> >service?
>
> Section 2.4 says that everything other than the From: header is out of
> scome. Section 11.4 describes display name attacks and it looks OK to
> me. I suppose we might tweak 2.4 to clarify that anything other than
> the mailbox in the RFC5322.From field is out of scope to avoid any
> implication that we're talking about the comment part.
>
> +1
>
> It's not exactly a secret that bad guys can use misleading connents as
> easily as good gyys. If we tried to enumerate all the ways that people
> might do dumb things, we would die of old age before we finished so I
> would prefer not to start.
>

+1

>
> At M3 people occasionally have talked about extending DMARC to cover
> the From comment but it's such an ill-defined problem (what's
> allowable? how could you tell?) that it has never gone anywhere.
>

There are things that can be done but to me they fall under local policy
and not interoperability. For example, if an email address is displayed but
doesn't match the From email address, don't display it. Some sites never
display the comment and only display the From email address. Things like
that.

Michael Hammer
___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

Re: [dmarc-ietf] Signaling MLMs

[Hector Santos]

> On Apr 16, 2023, at 11:31 PM, Benny Pedersen  wrote:
> 
> Hector Santos skrev den 2023-04-17 05:06:
> 
>> Anyway, there are far too much waste in electronic mail, ADSP/DMARC
>> and this quest to resolve its issues, creating more junk, ARC, is not
>> getting anywhere.
> 
> ?, spamassassin 4, do something, i use fuglu in prequeue smtpd postfix, works 
> for me atleast, it sometimes helps to be a gentoo ebuild maintainer, i still 
> like to find proxy maintainers helping me
> 
> with arc its sadly appled AFTER mailman have scrampled dkim :/
> 
> arc sign/seal should be done on incomming mails, not on outgoing


Thanks for the information.

Just consider your message source. The header overhead is massively complex to 
read. It is really a waste on receivers.

The final Auth-Result for your message:


Authentication-Results: dkim.winserver.com;
 dkim=pass header.d=ietf.org header.s=ietf1 header.i=ietf.org;
 dmarc=fail policy=none author.d=junc.eu signer.d=ietf.org 
(unauthorized signer);
 dkim=pass header.d=ietf.org header.s=ietf1 header.i=ietf.org;
 dmarc=fail policy=none author.d=junc.eu signer.d=ietf.org 
(unauthorized signer);
 dkim=fail (DKIM_BODY_HASH_MISMATCH) header.d=junc.eu header.s=default 
header.i=@junc.eu;
 dmarc=dkim-fail policy=none author.d=junc.eu signer.d=junc.eu 
(originating signer);


One solution is for the junc.eu domain to add an ATPS authorization record for 
ietf.org  to the junc.eu  zone:

pq6xadozsi47rluiq5yohg2hy3mvjyoo._atps  TXT ("v=atps01; d=ietf.org;")
to authorize the signer domain ietf.org:

See the wcDMARC wizard:


https://winserver.com/public/wcDmarc


—
HLS___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

Re: [dmarc-ietf] Is From spoofing an interoperability issue or not?

[John Levine]

It appears that Laura Atkins   said:
>Is this another issue we should document and make recommendations about? I was 
>thinking along the line that transactional SaaS
>providers should fully support DMARC and should not allow companies using 
>p=reject in their business mail to access the
>service? 

Section 2.4 says that everything other than the From: header is out of
scome. Section 11.4 describes display name attacks and it looks OK to
me. I suppose we might tweak 2.4 to clarify that anything other than
the mailbox in the RFC5322.From field is out of scope to avoid any
implication that we're talking about the comment part.

It's not exactly a secret that bad guys can use misleading connents as
easily as good gyys. If we tried to enumerate all the ways that people
might do dumb things, we would die of old age before we finished so I
would prefer not to start.

At M3 people occasionally have talked about extending DMARC to cover
the From comment but it's such an ill-defined problem (what's
allowable? how could you tell?) that it has never gone anywhere.

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?

[Hector Santos]

On 4/17/2023 9:43 AM, Scott Kitterman wrote:


OK.  The discussion of the 5322.From comment through me off, I guess.

I think there's probably room for the IETF to document Bext Current Practices
(BCP) around DMARC usage.  I think it's a step beyond the interoperability
discussion we need for the DMARCbis protocol document.  Assuming we think we
know enough, we might consider that for additional WG scope after we have
(essentially) completed the currently chartered work.



From my readings, my support considerations are:

+1 Codifying a MUST NOT use p=reject for XYZ reasons,
+1 Changing status to Informational, Experimental.

We can't make this a "Standard" when the odds are extremely high there 
is going to be many addressing this DKIM POLICY problem that could not 
be resolved for the 2nd time in nearly 17 years, for the same 
reasons.  Thanks to DMARC.  We have more DKIM Policy advocates today.  
If have had this with ADSP, we would be debating MUST NOT use 
"Discardable" instead use "All".


We should piggyback off DMARC calls.  It would be nice to see support 
by the key cogs for section 4.4.3 and Extended Tag Extensions. 
Suggestion: Add some more text here regarding dealing with authorization.


I consider DMARC today as the new "railroad tracks," the DNS method to 
get a mail operations policy from the Author Domain.  But its policies 
are incomplete. We need to recognize there are other policies other 
than the most restrictive with perfect alignment. We had more 
flexibility with SSP and a few with ADSP  "must be signed by me" and 
"must be signed by someone."   More flexible.


--
Hector Santos,
https://santronics.com
https://winserver.com



___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

Re: [dmarc-ietf] Is From spoofing an interoperability issue or not?

[Scott Kitterman]

On Monday, April 17, 2023 9:37:55 AM EDT Laura Atkins wrote:
> > On 17 Apr 2023, at 14:15, Scott Kitterman  wrote:
> > 
> > On Monday, April 17, 2023 4:29:45 AM EDT Laura Atkins wrote:
> >> Reading through the various discussions about how to document the harm
> >> DMARC causes for general purpose domains, I started thinking.One way
> >> that a lot of major SaaS providers have chose to deal with DMARC is
> >> spoofing their customer’s in the 5322.from Comment string. There are
> >> numerous examples of this: Paypal, Docusign, Sage, Intuit are 4 big
> >> examples I can think of off the top of my head.
> >> 
> >> All of these companies send out financial or business mail on behalf of
> >> their customers, some of whom do use p=reject on their own domains. Some
> >> of
> >> them also use restrictive DMARC policies for this mail, others don’t.
> >> 
> >> Is this another issue we should document and make recommendations about?
> >> I
> >> was thinking along the line that transactional SaaS providers should
> >> fully
> >> support DMARC and should not allow companies using p=reject in their
> >> business mail to access the service?
> >> 
> >> I keep going back and forth that this is not an interoperability issue -
> >> the mail works fine even when the business is spoofed in the 5322.from
> >> comment string. But on a practical level it looks exactly like phishing
> >> mail because it’s financial (or contractual) docs from a particular
> >> company coming from a random domain. I keep ending up this isn’t an
> >> interoperability issue, it’s just an end run around DMARC and it’s not
> >> the
> >> IETF’s place to comment on that.
> >> 
> >> But I thought I’d bring the discussion up here to see if other folks had
> >> different opinions.
> > 
> > Many mailing lists do the same as part of their DMARC From re-writing
> > work-
> > around.
> > 
> > I think it's out of scope for DMARC.  DMARC is wired to 5322.from and not
> > the Comment string.
> 
> I apparently didn’t clearly express myself as both you and Michael
> misunderstood what I was saying.
> 
> 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?
> > The thing is, it's a comment string, so on what basis is any particular
> > comment good or bad?  That's a complicated question and I think we have
> > enough to do without trying to tackle this too.
> 
> I honestly wasn’t trying to bring up that discussion. I was more focused on
> ensuring SaaS companies can support DMARC. Many of them, even in the
> financial space, don’t currently do so.

OK.  The discussion of the 5322.From comment through me off, I guess.

I think there's probably room for the IETF to document Bext Current Practices 
(BCP) around DMARC usage.  I think it's a step beyond the interoperability 
discussion we need for the DMARCbis protocol document.  Assuming we think we 
know enough, we might consider that for additional WG scope after we have 
(essentially) completed the currently chartered work.

Scott K


___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

Re: [dmarc-ietf] Is From spoofing an interoperability issue or not?

[Laura Atkins]

> On 17 Apr 2023, at 14:15, Scott Kitterman  wrote:
> 
> On Monday, April 17, 2023 4:29:45 AM EDT Laura Atkins wrote:
>> Reading through the various discussions about how to document the harm DMARC
>> causes for general purpose domains, I started thinking.One way that a lot
>> of major SaaS providers have chose to deal with DMARC is spoofing their
>> customer’s in the 5322.from Comment string. There are numerous examples of
>> this: Paypal, Docusign, Sage, Intuit are 4 big examples I can think of off
>> the top of my head.
>> 
>> All of these companies send out financial or business mail on behalf of
>> their customers, some of whom do use p=reject on their own domains. Some of
>> them also use restrictive DMARC policies for this mail, others don’t.
>> 
>> Is this another issue we should document and make recommendations about? I
>> was thinking along the line that transactional SaaS providers should fully
>> support DMARC and should not allow companies using p=reject in their
>> business mail to access the service?
>> 
>> I keep going back and forth that this is not an interoperability issue - the
>> mail works fine even when the business is spoofed in the 5322.from comment
>> string. But on a practical level it looks exactly like phishing mail
>> because it’s financial (or contractual) docs from a particular company
>> coming from a random domain. I keep ending up this isn’t an
>> interoperability issue, it’s just an end run around DMARC and it’s not the
>> IETF’s place to comment on that.
>> 
>> But I thought I’d bring the discussion up here to see if other folks had
>> different opinions.
> 
> Many mailing lists do the same as part of their DMARC From re-writing work-
> around.
> 
> I think it's out of scope for DMARC.  DMARC is wired to 5322.from and not the 
> Comment string.

I apparently didn’t clearly express myself as both you and Michael 
misunderstood what I was saying. 

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?

> The thing is, it's a comment string, so on what basis is any particular 
> comment good or bad?  That's a complicated question and I think we have 
> enough 
> to do without trying to tackle this too.

I honestly wasn’t trying to bring up that discussion. I was more focused on 
ensuring SaaS companies can support DMARC. Many of them, even in the financial 
space, don’t currently do so. 

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?

[Laura Atkins]

> On 17 Apr 2023, at 14:01, Dotzero  wrote:
> 
> 
> 
> On Mon, Apr 17, 2023 at 4:30 AM Laura Atkins  > wrote:
>> Reading through the various discussions about how to document the harm DMARC 
>> causes for general purpose domains, I started thinking.One way that a lot of 
>> major SaaS providers have chose to deal with DMARC is spoofing their 
>> customer’s in the 5322.from Comment string. There are numerous examples of 
>> this: Paypal, Docusign, Sage, Intuit are 4 big examples I can think of off 
>> the top of my head. 
>> 
>> All of these companies send out financial or business mail on behalf of 
>> their customers, some of whom do use p=reject on their own domains. Some of 
>> them also use restrictive DMARC policies for this mail, others don’t. 
>> 
>> Is this another issue we should document and make recommendations about? I 
>> was thinking along the line that transactional SaaS providers should fully 
>> support DMARC and should not allow companies using p=reject in their 
>> business mail to access the service? 
> 
> Let's throw the baby out with the bath water. There are ways a 
> (transactional) domain owner can enable a vendor to generate/send email on 
> their behalf without the vendor "spoofing" the domain. A subdomain can be 
> delegated, private DKIM signing keys can be provided. Another approach is 
> routing outbound email from the vendor through the customer's mail servers.  
> In addition, dedicated sending IPs can be required by the customer. My 
> personal favorite is delegating a subdomain because all of the obligations 
> can easily be specified contractually. In the past when potential vendors 
> have said "we don't do that" or "we can't do that" and I've said "then we 
> can't consider you in our vendor election process", it's amazing how quickly 
> they figure out how to do things if there is enough money on the table. I 
> speak from experience.
> 
> If enough people insist then vendors will productize these approaches into 
> their offerings more generally. It's a competitive differentiator until 
> enough vendors have offerings, at which time it will become the ante to play 
> in the game. So no, suggesting that the only solution is vendors rejecting 
> business from customers who publish p=reject is pretty much a non-starter.

That would be why the first part of my statement was that SaaS providers should 
fully support DMARC. As in, they should have the ability to provide both SPF 
and DKIM alignment for customers to implement. Many of them don’t currently do 
that - and many of us aren’t a billion dollar company and get told “well, 
sorry, that’s simply not something we find important.” 

>> 
>> I keep going back and forth that this is not an interoperability issue - the 
>> mail works fine even when the business is spoofed in the 5322.from comment 
>> string. But on a practical level it looks exactly like phishing mail because 
>> it’s financial (or contractual) docs from a particular company coming from a 
>> random domain. I keep ending up this isn’t an interoperability issue, it’s 
>> just an end run around DMARC and it’s not the IETF’s place to comment on 
>> that. 
> 
> I could see a discussion in a BCP as to why it's a bad practice. I don't see 
> it having a place in a standard.

Do you really think the IETF has no role in saying ‘if you send mail on behalf 
of other companies, you should be able to allow that company to authenticate 
their email in a DMARC compliant way?’

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?

[Douglas Foster]

The only real fix for Friendly Name fraud is to strip it away, except for
trusted domains that have been verified with DMARC PASS.

Major vendors are trying lesser solutions by preventing friendly name
impersonation of key executives, but the problem is much greater.

This topic is material for a subsequent document, but may have to be done
outside of IETF since Friendly Name fraud prevention is not a protocol.

Doug

On Mon, Apr 17, 2023, 9:01 AM Dotzero  wrote:

>
>
> On Mon, Apr 17, 2023 at 4:30 AM Laura Atkins 
> wrote:
>
>> Reading through the various discussions about how to document the harm
>> DMARC causes for general purpose domains, I started thinking.One way that a
>> lot of major SaaS providers have chose to deal with DMARC is spoofing their
>> customer’s in the 5322.from Comment string. There are numerous examples of
>> this: Paypal, Docusign, Sage, Intuit are 4 big examples I can think of off
>> the top of my head.
>>
>> All of these companies send out financial or business mail on behalf of
>> their customers, some of whom do use p=reject on their own domains. Some of
>> them also use restrictive DMARC policies for this mail, others don’t.
>>
>> Is this another issue we should document and make recommendations about?
>> I was thinking along the line that transactional SaaS providers should
>> fully support DMARC and should not allow companies using p=reject in their
>> business mail to access the service?
>>
>
> Let's throw the baby out with the bath water. There are ways a
> (transactional) domain owner can enable a vendor to generate/send email on
> their behalf without the vendor "spoofing" the domain. A subdomain can be
> delegated, private DKIM signing keys can be provided. Another approach is
> routing outbound email from the vendor through the customer's mail
> servers.  In addition, dedicated sending IPs can be required by the
> customer. My personal favorite is delegating a subdomain because all of the
> obligations can easily be specified contractually. In the past when
> potential vendors have said "we don't do that" or "we can't do that" and
> I've said "then we can't consider you in our vendor election process", it's
> amazing how quickly they figure out how to do things if there is enough
> money on the table. I speak from experience.
>
> If enough people insist then vendors will productize these approaches into
> their offerings more generally. It's a competitive differentiator until
> enough vendors have offerings, at which time it will become the ante to
> play in the game. So no, suggesting that the only solution is vendors
> rejecting business from customers who publish p=reject is pretty much a
> non-starter.
>
>
>>
>> I keep going back and forth that this is not an interoperability issue -
>> the mail works fine even when the business is spoofed in the 5322.from
>> comment string. But on a practical level it looks exactly like phishing
>> mail because it’s financial (or contractual) docs from a particular company
>> coming from a random domain. I keep ending up this isn’t an
>> interoperability issue, it’s just an end run around DMARC and it’s not the
>> IETF’s place to comment on that.
>>
>
> I could see a discussion in a BCP as to why it's a bad practice. I don't
> see it having a place in a standard.
>
> Michael Hammer
> ___
> 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] Is From spoofing an interoperability issue or not?

[Scott Kitterman]

On Monday, April 17, 2023 4:29:45 AM EDT Laura Atkins wrote:
> Reading through the various discussions about how to document the harm DMARC
> causes for general purpose domains, I started thinking.One way that a lot
> of major SaaS providers have chose to deal with DMARC is spoofing their
> customer’s in the 5322.from Comment string. There are numerous examples of
> this: Paypal, Docusign, Sage, Intuit are 4 big examples I can think of off
> the top of my head.
> 
> All of these companies send out financial or business mail on behalf of
> their customers, some of whom do use p=reject on their own domains. Some of
> them also use restrictive DMARC policies for this mail, others don’t.
> 
> Is this another issue we should document and make recommendations about? I
> was thinking along the line that transactional SaaS providers should fully
> support DMARC and should not allow companies using p=reject in their
> business mail to access the service?
> 
> I keep going back and forth that this is not an interoperability issue - the
> mail works fine even when the business is spoofed in the 5322.from comment
> string. But on a practical level it looks exactly like phishing mail
> because it’s financial (or contractual) docs from a particular company
> coming from a random domain. I keep ending up this isn’t an
> interoperability issue, it’s just an end run around DMARC and it’s not the
> IETF’s place to comment on that.
> 
> But I thought I’d bring the discussion up here to see if other folks had
> different opinions.

Many mailing lists do the same as part of their DMARC From re-writing work-
around.

I think it's out of scope for DMARC.  DMARC is wired to 5322.from and not the 
Comment string.

The thing is, it's a comment string, so on what basis is any particular 
comment good or bad?  That's a complicated question and I think we have enough 
to do without trying to tackle this too.

Scott K


___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

Re: [dmarc-ietf] Is From spoofing an interoperability issue or not?

[Dotzero]

On Mon, Apr 17, 2023 at 4:30 AM Laura Atkins 
wrote:

> Reading through the various discussions about how to document the harm
> DMARC causes for general purpose domains, I started thinking.One way that a
> lot of major SaaS providers have chose to deal with DMARC is spoofing their
> customer’s in the 5322.from Comment string. There are numerous examples of
> this: Paypal, Docusign, Sage, Intuit are 4 big examples I can think of off
> the top of my head.
>
> All of these companies send out financial or business mail on behalf of
> their customers, some of whom do use p=reject on their own domains. Some of
> them also use restrictive DMARC policies for this mail, others don’t.
>
> Is this another issue we should document and make recommendations about? I
> was thinking along the line that transactional SaaS providers should fully
> support DMARC and should not allow companies using p=reject in their
> business mail to access the service?
>

Let's throw the baby out with the bath water. There are ways a
(transactional) domain owner can enable a vendor to generate/send email on
their behalf without the vendor "spoofing" the domain. A subdomain can be
delegated, private DKIM signing keys can be provided. Another approach is
routing outbound email from the vendor through the customer's mail
servers.  In addition, dedicated sending IPs can be required by the
customer. My personal favorite is delegating a subdomain because all of the
obligations can easily be specified contractually. In the past when
potential vendors have said "we don't do that" or "we can't do that" and
I've said "then we can't consider you in our vendor election process", it's
amazing how quickly they figure out how to do things if there is enough
money on the table. I speak from experience.

If enough people insist then vendors will productize these approaches into
their offerings more generally. It's a competitive differentiator until
enough vendors have offerings, at which time it will become the ante to
play in the game. So no, suggesting that the only solution is vendors
rejecting business from customers who publish p=reject is pretty much a
non-starter.


>
> I keep going back and forth that this is not an interoperability issue -
> the mail works fine even when the business is spoofed in the 5322.from
> comment string. But on a practical level it looks exactly like phishing
> mail because it’s financial (or contractual) docs from a particular company
> coming from a random domain. I keep ending up this isn’t an
> interoperability issue, it’s just an end run around DMARC and it’s not the
> IETF’s place to comment on that.
>

I could see a discussion in a BCP as to why it's a bad practice. I don't
see it having a place in a standard.

Michael Hammer
___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

Re: [dmarc-ietf] Example of Indirect Mail Flow Breakage with p=reject?

[Alessandro Vesely]

On Mon 17/Apr/2023 07:05:47 +0200 Murray S. Kucherawy wrote:

On Sat, Apr 15, 2023 at 3:58 PM Neil Anuskiewicz wrote:

1. Cousin domains. We all get that dmarc doesn’t touch those. Dmarc is to 
stop spoofing of exact domains. There are other technologies and methods 
whose responsibility it is to track down and take down fraudsters.


The claim was made that DMARC solves a real problem, which is direct domain 
attacks.  I don't think anyone doubts this to be true when it's used in 
transaction-only scenarios (the opposite of what we're now calling "general 
purpose" domains).


There are two things I think that are important to resolve, and not dismiss 
as red herrings:


(1) Exactly how much of a win is it when it's used in a way that disrupts 
normal operations?  This may turn out to be a value judgement to some 
people, pitting the value of what DMARC actually solves against the value 
of what it breaks.  This is extra challenging given the IETF's bias toward 
preferring things that interoperate.



Not much, IMHO.  We're halfway in the middle of the ford.  Perhaps halfway+.


(2) Exactly how much of a win is it when attackers can simply change the 
domain they're using, use a display name attack, and still successfully 
attack the same operator?  If the size of what it defeats turns out to be 
small relative to the overall attack space, then I think the answer to this 
question influences the answer to the first one.



We need to be careful here.  On the one hand, putting a strong barrier will aid 
building additional defenses around it, such as identifying cousin domains, 
mixed alphabets, and spoofed From: lines.  On the other hand, we force mailing 
list to create such spoofed From: lines, and consequently force end users to 
accept them.  (Is that the residual ML rejections that Barry complains about?) 
We should mention this point, and grant citizenship to (some of) those constructs.




I think we should expect that these are the sorts of questions on which we
will be challenged when we send this work out to the wider IETF.  Punting
on them as unimportant is not likely to result in a smooth ride.



Most probably you're right, but we'll cross that bridge when we come to it.


jm2c
Ale
--





___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

[dmarc-ietf] Is From spoofing an interoperability issue or not?

[Laura Atkins]

Reading through the various discussions about how to document the harm DMARC 
causes for general purpose domains, I started thinking.One way that a lot of 
major SaaS providers have chose to deal with DMARC is spoofing their customer’s 
in the 5322.from Comment string. There are numerous examples of this: Paypal, 
Docusign, Sage, Intuit are 4 big examples I can think of off the top of my 
head. 

All of these companies send out financial or business mail on behalf of their 
customers, some of whom do use p=reject on their own domains. Some of them also 
use restrictive DMARC policies for this mail, others don’t. 

Is this another issue we should document and make recommendations about? I was 
thinking along the line that transactional SaaS providers should fully support 
DMARC and should not allow companies using p=reject in their business mail to 
access the service? 

I keep going back and forth that this is not an interoperability issue - the 
mail works fine even when the business is spoofed in the 5322.from comment 
string. But on a practical level it looks exactly like phishing mail because 
it’s financial (or contractual) docs from a particular company coming from a 
random domain. I keep ending up this isn’t an interoperability issue, it’s just 
an end run around DMARC and it’s not the IETF’s place to comment on that. 

But I thought I’d bring the discussion up here to see if other folks had 
different opinions.

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