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

[Alessandro Vesely]

On Fri 21/Apr/2023 18:43:30 +0200 Scott Kitterman wrote:

On April 21, 2023 3:57:54 PM UTC, Alessandro Vesely  wrote:

On Fri 21/Apr/2023 05:41:03 +0200 Scott Kitterman wrote:

On April 20, 2023 4:18:08 PM UTC, Dotzero  wrote:

On Thu, Apr 20, 2023 at 11:38 AM John Levine  wrote:

It appears that Alessandro Vesely   said:


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. >>>

Absolutely not. This sort of thing is utterly outside the scope of our job and 
wasting time on it just further delays our already extremely late work.


+1

There are many things John and I may disagree on but he clearly understands why 
avoiding scope creep (and bad ideas) is important.


Definitely agree with both of you on this.


Eeeh, what an uprising!  I just proposed a couple of paragraphs, not a new 
rocket science theory.

As for the badness, why wouldn't a concise but detailed explanation be better 
than obscure forbiddings and dark forebodings, such as MUST NOT be used by 
humans or interoperability will break down?

BTW, what's the outcome of that discussion?


That, specifically is a question for the chairs, so no idea.



My recollection is that Barry said a Proposed Standard can get away without 
MUST NOT.  Had we been we aiming at full standard directly before?




There are a nearly infinite set of few paragraphs we could write that would 
make things clearer.  If we ever want to finish this, some of them need to be 
out of scope.



Fully agreed.  However, I think we must select out of that "nearly infinite 
set" the paragraphs that explain the MLM issue and other interoperability 
damage, which includes From: rewriting.


Meanwhile, digressions about ATPS and similar schemes can help casting some 
light on future evolution.  From: rewriting cannot be the final solution; it is 
a temporary hack.  Digressions don't slow down the publication, as discussions 
about actual text quickly prevail.  They are just a mean to help convergence 
toward a common vision of the future.



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?

[Scott Kitterman]

On April 21, 2023 3:57:54 PM UTC, Alessandro Vesely  wrote:
>On Fri 21/Apr/2023 05:41:03 +0200 Scott Kitterman wrote:
>> On April 20, 2023 4:18:08 PM UTC, Dotzero  wrote:
>>> On Thu, Apr 20, 2023 at 11:38 AM John Levine  wrote:
 It appears that Alessandro Vesely   said:
 
> 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. >>>
 Absolutely not. This sort of thing is utterly outside the scope of our job 
 and wasting time on it just further delays our already extremely late work.
>>> 
>>> +1
>>> 
>>> There are many things John and I may disagree on but he clearly understands 
>>> why avoiding scope creep (and bad ideas) is important.
>> 
>> Definitely agree with both of you on this.
>
>
>Eeeh, what an uprising!  I just proposed a couple of paragraphs, not a new 
>rocket science theory.
>
>As for the badness, why wouldn't a concise but detailed explanation be better 
>than obscure forbiddings and dark forebodings, such as MUST NOT be used by 
>humans or interoperability will break down?
>
>BTW, what's the outcome of that discussion?

That, specifically is a question for the chairs, so no idea.

There are a nearly infinite set of few paragraphs we could write that would 
make things clearer.  If we ever want to finish this, some of them need to be 
out of scope.

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?

[Alessandro Vesely]

On Fri 21/Apr/2023 05:41:03 +0200 Scott Kitterman wrote:

On April 20, 2023 4:18:08 PM UTC, Dotzero  wrote:

On Thu, Apr 20, 2023 at 11:38 AM John Levine  wrote:

It appears that Alessandro Vesely   said:

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. >>>
Absolutely not. This sort of thing is utterly outside the scope of our 
job and wasting time on it just further delays our already extremely 
late work.


+1

There are many things John and I may disagree on but he clearly understands 
why avoiding scope creep (and bad ideas) is important.


Definitely agree with both of you on this.



Eeeh, what an uprising!  I just proposed a couple of paragraphs, not a new 
rocket science theory.


As for the badness, why wouldn't a concise but detailed explanation be better 
than obscure forbiddings and dark forebodings, such as MUST NOT be used by 
humans or interoperability will break down?


BTW, what's the outcome of that discussion?


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?

[Scott Kitterman]

On April 20, 2023 4:18:08 PM UTC, Dotzero  wrote:
>On Thu, Apr 20, 2023 at 11:38 AM John Levine  wrote:
>
>> It appears that Alessandro Vesely   said:
>> >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.
>>
>> Absolutely not. This sort of thing is utterly outside the scope of our
>> job and wasting time on it just further delays our already extremely
>> late work.
>>
>> R's,
>> John
>>
>
>+1
>
>There are many things John and I may disagree on but he clearly understands
>why avoiding scope creep (and bad ideas) is important.

Definitely agree with both of you on this.

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?

[Hector Santos]

> On Apr 19, 2023, at 10:29 PM, Jesse Thompson  wrote:
> 
> 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

This will cause the list bounce problem.  This was seen immediately in the IETF 
list when it 100% ignorance of DKIM.  Signatures broke.  

Solution: Support DKIM and resign as 3rd party
Problem: Policy does not allow a resigner.

No one honored broken signatures, policies. Recorded as fail but no lost until 
YAHOO shook the world and began to honor p=reject policies.  Bounce problem.


> 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.
> 

We allowed a protocol incomplete to take off without dealing with the known 
potential problem.  No one will honor DKIM policy stuff.

Now its broken.

As a Mailing List Server developer, we need a migration path to a 3rd option 
(ATPS concept) which using #2 temporarily.   Ideally no From destruction is the 
goal.  For now, I use #2 restrictions on subscription and submissions 

—
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?

[Dotzero]

On Thu, Apr 20, 2023 at 11:38 AM John Levine  wrote:

> It appears that Alessandro Vesely   said:
> >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.
>
> Absolutely not. This sort of thing is utterly outside the scope of our
> job and wasting time on it just further delays our already extremely
> late work.
>
> R's,
> John
>

+1

There are many things John and I may disagree on but he clearly understands
why avoiding scope creep (and bad ideas) is important.

Michael Hammer
___
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 Alessandro Vesely   said:
>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.

Absolutely not. This sort of thing is utterly outside the scope of our
job and wasting time on it just further delays our already extremely
late work.

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?

[Douglas Foster]

If a vendor wants to serve a customer, he needs to provide a product that
the customer can use.   I don't see that it is IETFs problem to worry about
a vendor with an inadequate email platform, especially since DMARC has been
around awhile.

But I have been thinking further about the constrained delegation issue.
 The general goal, at least for a single mailing is:
User2@Domain2 needs to be authorized to email for User1@Domain1.

DKIM authorizes anyone with the private key to email for anyuser@Domain1.
 The domain owner has to worry about multiple things:

   - Unauthorized Use For:   Will domain2 will use the key for any messages
   other then User1@Domain1?
   - Unauthorized Use By:   Will Others@Domain2 use the key for
   User2@Domain2?
   - Theft:  Will be stolen and used by HostileUser@HostileDomain.

Adjusting delegation:

   - Hector's ATSP proposal limits the delegation to Domain2.
@HostileDomain cannot steal the delegation, because the delegation only
   works if a domain is authenticated by @domain1 and has signed the message.
For a high-sensitivity domain like @WhiteHouse.Gov, they may want to
   require both:   @Domain2 must have a DKIM private key for @Domain1
   AND @Domain2 must have an ATSP delegation from @Domin1.

   - DKIMs "I=" clause can be used to limit the "Use For".   A signature
   configured with "d=domain1; i=user1@domain1" should only authenticate
   messages with "From: user1@domain1".   This is an upward-compatible
   change in the way DMARC interprets DKIM, not a layer violation of DKIM.
This could be used two ways:  (a) possession of the private key permits
   use to send on behalf of "user1@domain1", and (b) ATSP could provide
   user-level delegation to only messages counter-signed by user2@domain2.

   - Subdomains can be used to limit scope:   Issuing a key for
   @subdomain1.domain1 is more limited risk than issuing a key for @domain1.
   - Subdomains with p=none can be used to allow a subset of messages to be
   sent unauthenticated.  In some cases, allowing @subdomain.domain1 to
   operate unauthenticated may be perceived as lower risk than issuing a DKIM
   private key.


The UseF


On Wed, Apr 19, 2023 at 10:30 PM Jesse Thompson  wrote:

> 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
>
___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

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

[Jesse Thompson]

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?

[Alessandro Vesely]

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] Is From spoofing an interoperability issue or not?

[John Levine]

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?

[Scott Kitterman]

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] Is From spoofing an interoperability issue or not?

[Laura Atkins]

> 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?

[John Levine]

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] Is From spoofing an interoperability issue or not?

[Jesse Thompson]

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.

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?

[Hector Santos]

On Apr 18, 2023, at 1:11 PM, Alessandro Vesely  wrote:
> 
> Perhaps when DMARC will work smoothly, someone will find out how to tell 
> legitimate rewriting from plain spoof.
> 

Lookup DMARC record and begin to piggy back off this lookup:

- Check for rewrite=1 tag indicating allowance to rewrite. 

- Check for asl= or atps=y signer authorization.

If the domain tells the resigner he can destroy the authorship, you now have a 
legitimate protocol negotiated handshake/contract. I prefer if there was an 
explicit authorization using asl= or atps=y, but an open ended rewrite=1 tag is 
fine, I think.  It is permission the domain is giving to resigners.

—
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?

[Alessandro Vesely]

On Mon 17/Apr/2023 22:59:29 +0200 Dotzero wrote:

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 
scope. 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 comments as 
easily as good guys. 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



Section 11.4 also brings an example of rewritten From:.  It doesn't say that 
that in several cases doing such sort of construct is necessary because of 
DMARC.  Perhaps it could?



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.



Perhaps when DMARC will work smoothly, someone will find out how to tell 
legitimate rewriting from plain spoof.



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?

[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] 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

[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