Re: [dmarc-ietf] Protocols All The Way Down (long - sorry)

[Dotzero]

On Wed, Jul 12, 2023 at 6:47 AM Scott Kitterman 
wrote:

> It's not news that there's a risk for SPF associated with shared IP
> addresses.
> That's why it's in RFC 7208 (11.4) and was in RFC 4408 similarly before.
>

+1


>
> I understand your view and agree on the problem.  I also sympathize with
> the
> need to technically address conditions as they exist in operations.  I'm
> not
> convinced that we should bake the solutions into protocol, however.
>
> As I've said before, I think this is primarily and economics/incentives
> problem, not a technical problem.  If you increase the incentives for
> third
> party providers to support DKIM in place of SPF, I don't think you've
> actually
> solved anything.
>

The reality is that many ESPs have asked "how does DMARC fit into my
business model?". My response has always been that it is not up to the
community to figure out your business model.


> As fas as I've seen, the low cost (for a third party to sign using their
> customer's domain name) approach is for the third party provider to
> publish
> DKIM key records based on their own private keys and then tell their
> customer
> to put a CNAME in their DNS that points to it.  In the case of a shared
> server, the third party provider then needs to keep track of which
> customer is
> authorized to sign for which d= domain, but they can use their own keys/
> infrastructure for doing so.
>

That is one approach. We used to delegate subdomains and contractually
require key rotation, etc. We did that after 2007 (due to Storm Worm), well
before DMARC was published. There were ESPs that balked at signing with our
keys and they were not considered as potential vendors. There were others
that worked with us and also provided dedicated IPs that were shared among
our various brands (for SPF). Many folks lag behind because they perceive
the "cost" of security as higher than the cost(s) associated with the
consequences of poor practices.

A slightly more complicated approach would be for the domain to provide
private signing keys to the 3rd party.


>
> The internal management function of keeping track of which customers can
> use
> which signing domains is essentially the same as the internal management
> function of keeping track of which customers can use which Mail From
> addresses
> with SPF.
>
> My speculation (and it is that), is that the most cost sensitive third
> party
> providers currently use SPF only and are less likely to keep effective
> control
> of which customer can send from which identity precisely because it's less
> expensive.  If you change the deployment incentives so that DKIM is now
> more
> necessary for some of their customers, they'll no doubt deploy it, but
> without
> better internal controls, you'll end up with the same problems with these
> providers expressed through a different technology.
>

In some ways, receivers/mailbox providers enable the bad practices by
accepting problematic email because that requires less work in dealing with
the ISP Relations people from those mailers. As a sidenote, one need only
look at the ratio of deliverability people to compliance people at some of
these organizations to understand priorities. A harder line would force
those mailers to reevaluate their practices and offerings. This is an
operations/implementation problem and not so much a protocol/standards
problem. Just saying.

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

Re: [dmarc-ietf] Another p=reject text proposal

[Douglas Foster]

Does anyone believe that things will change if we publish an RFC which says
"Verizon Media MUST change to p=none"?  I don't.

Lists have been hurt by the move to authenticated email.  Point taken.
However, the world is not going back to the good old days,.

There is no hope for a list solution to appear from outside the list
community.  If or when list advocates reconcile themselves to that reality,
we can start making real headway on solving the problem.  The outlines of
the solution have been on the table for several years already.  But those
solutions have been ignored because list advocates are waiting for everyone
else to change to meet list needs.

DF



On Wed, Jul 12, 2023, 3:30 AM Baptiste Carvello <
devel2...@baptiste-carvello.net> wrote:

> Hi,
>
> Le 08/07/2023 à 20:24, Scott Kitterman a écrit :
> >
> > You can equally argue that these receivers are merely following the
> policy advice provided by the sending domain (it has reject right in the
> name) and this problem is entirely generated by sender's inappropriate use
> of p=reject.
> >
> > I don't think engineering the location where the blame lands is the
> right place to focus.  I've done plenty of blame avoidance engineering in
> my day, but I don't think it's what the IETF should be doing.
>
> This is not about blame avoidance. Blame avoidance is what happens right
> now on this very list, with author domains and mail receivers first
> blaming each other, then colluding to accuse absentee forwarders…
>
> This is about avoiding the Tragedy of Commons where everyone waits for
> the breakage to somehow solve itself (or, more cynically, for the victim
> to resignate). The standard can help by clearly stating who has to act
> in which circumstances. A MUST is better than a SHOULD, an it might well
> be that two SHOULDs are worse than just one.
>
> Cheers,
> Baptiste
>
> ___
> 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] SMTP Result Codes was -Re: Another p=reject text proposal

[Todd Herr]

On Wed, Jul 12, 2023 at 7:30 AM Scott Kitterman 
wrote:

> On Wednesday, July 12, 2023 7:04:38 AM EDT Alessandro Vesely wrote:
> > On Wed 12/Jul/2023 12:54:38 +0200 Scott Kitterman wrote:
> > > On Wednesday, July 12, 2023 3:29:34 AM EDT Baptiste Carvello wrote:
> > > ...
> > >
> > >> Why? Because it's brittle and will only bring them more headaches? At
> > >> the very least, DMARC would need to use its own 5xy reply code to
> avoid
> > >> the need for parsing the reply text…
> > >
> > > This is a very good point.  The IANA Simple Mail Transfer Protocol
> (SMTP)
> > > Enhanced Status Codes Registry [1] has codes for SPF and DKIM (RFC
> 7372)
> > > and ARC (RFC 8617), but not DMARC.  Adding one is not currently in the
> > > DMARCbis draft, but I think it should be.
> >
> > +1; still, having the word "DMARC" in the text greatly simplifies parsing
> > logs.
> >
> >
> > I noted that Baptiste wrote 5xx, not 5.x.x.  5xx has to be 550 methinks.
>
> I agree re 550.  Also, if I were writing the reject message that goes
> after
> the code, I would include DMARC in it.  I suspect most will for human
> readability, but programatically, I'd use the codes if present.
>

Google uses 5.7.26 for the purpose (and for SPF and DKIM rejects):

https://support.google.com/a/answer/3726730?sjid=16541570162287939258-NA

Their use of 5.7.26 seems in keeping with IANA - Multiple authentication
checks failed - since in order to fail DMARC, both SPF and DKIM must fail.

https://www.iana.org/assignments/smtp-enhanced-status-codes/smtp-enhanced-status-codes.xhtml
-- 

*Todd Herr * | Technical Director, Standards & Ecosystem
*e:* todd.h...@valimail.com
*p:* 703-220-4153
*m:* 703.220.4153

This email and all data transmitted with it contains confidential and/or
proprietary information intended solely for the use of individual(s)
authorized to receive it. If you are not an intended and authorized
recipient you are hereby notified of any use, disclosure, copying or
distribution of the information included in this transmission is prohibited
and may be unlawful. Please immediately notify the sender by replying to
this email and then delete it from your system.
___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

Re: [dmarc-ietf] SMTP Result Codes was -Re: Another p=reject text proposal

[Scott Kitterman]

On Wednesday, July 12, 2023 7:04:38 AM EDT Alessandro Vesely wrote:
> On Wed 12/Jul/2023 12:54:38 +0200 Scott Kitterman wrote:
> > On Wednesday, July 12, 2023 3:29:34 AM EDT Baptiste Carvello wrote:
> > ...
> > 
> >> Why? Because it's brittle and will only bring them more headaches? At
> >> the very least, DMARC would need to use its own 5xy reply code to avoid
> >> the need for parsing the reply text…
> > 
> > This is a very good point.  The IANA Simple Mail Transfer Protocol (SMTP)
> > Enhanced Status Codes Registry [1] has codes for SPF and DKIM (RFC 7372)
> > and ARC (RFC 8617), but not DMARC.  Adding one is not currently in the
> > DMARCbis draft, but I think it should be.
> 
> +1; still, having the word "DMARC" in the text greatly simplifies parsing
> logs.
> 
> 
> I noted that Baptiste wrote 5xx, not 5.x.x.  5xx has to be 550 methinks.

I agree re 550.  Also, if I were writing the reject message that goes after 
the code, I would include DMARC in it.  I suspect most will for human 
readability, but programatically, I'd use the codes if present.

Scott K


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

Re: [dmarc-ietf] SMTP Result Codes was -Re: Another p=reject text proposal

[Alessandro Vesely]

On Wed 12/Jul/2023 12:54:38 +0200 Scott Kitterman wrote:

On Wednesday, July 12, 2023 3:29:34 AM EDT Baptiste Carvello wrote:
...

Why? Because it's brittle and will only bring them more headaches? At
the very least, DMARC would need to use its own 5xy reply code to avoid
the need for parsing the reply text…


This is a very good point.  The IANA Simple Mail Transfer Protocol (SMTP)
Enhanced Status Codes Registry [1] has codes for SPF and DKIM (RFC 7372) and
ARC (RFC 8617), but not DMARC.  Adding one is not currently in the DMARCbis
draft, but I think it should be.



+1; still, having the word "DMARC" in the text greatly simplifies parsing logs.


I noted that Baptiste wrote 5xx, not 5.x.x.  5xx has to be 550 methinks.


Best
Ale
--





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

[dmarc-ietf] SMTP Result Codes was -Re: Another p=reject text proposal

[Scott Kitterman]

On Wednesday, July 12, 2023 3:29:34 AM EDT Baptiste Carvello wrote:
...
> Why? Because it's brittle and will only bring them more headaches? At
> the very least, DMARC would need to use its own 5xy reply code to avoid
> the need for parsing the reply text…
...

This is a very good point.  The IANA Simple Mail Transfer Protocol (SMTP) 
Enhanced Status Codes Registry [1] has codes for SPF and DKIM (RFC 7372) and 
ARC (RFC 8617), but not DMARC.  Adding one is not currently in the DMARCbis 
draft, but I think it should be.

Scott K

[1] 
https://www.iana.org/assignments/smtp-enhanced-status-codes/smtp-enhanced-status-codes.xhtml


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

Re: [dmarc-ietf] Protocols All The Way Down (long - sorry)

[Scott Kitterman]

It's not news that there's a risk for SPF associated with shared IP addresses.  
That's why it's in RFC 7208 (11.4) and was in RFC 4408 similarly before.

I understand your view and agree on the problem.  I also sympathize with the 
need to technically address conditions as they exist in operations.  I'm not 
convinced that we should bake the solutions into protocol, however.

As I've said before, I think this is primarily and economics/incentives 
problem, not a technical problem.  If you increase the incentives for third 
party providers to support DKIM in place of SPF, I don't think you've actually 
solved anything.

As fas as I've seen, the low cost (for a third party to sign using their 
customer's domain name) approach is for the third party provider to publish 
DKIM key records based on their own private keys and then tell their customer 
to put a CNAME in their DNS that points to it.  In the case of a shared 
server, the third party provider then needs to keep track of which customer is 
authorized to sign for which d= domain, but they can use their own keys/
infrastructure for doing so.

The internal management function of keeping track of which customers can use 
which signing domains is essentially the same as the internal management 
function of keeping track of which customers can use which Mail From addresses 
with SPF.

My speculation (and it is that), is that the most cost sensitive third party 
providers currently use SPF only and are less likely to keep effective control 
of which customer can send from which identity precisely because it's less 
expensive.  If you change the deployment incentives so that DKIM is now more 
necessary for some of their customers, they'll no doubt deploy it, but without 
better internal controls, you'll end up with the same problems with these 
providers expressed through a different technology.

Scott K

On Tuesday, July 11, 2023 8:49:28 PM EDT Wei Chuang wrote:
> The data we presented June 20th (archive
> )
> also suggests that it is premature to drop SPF from DMARC.  However I
> differ in believing that we should accept the spoofing risk demonstrated
> recently via SPF, and that we shouldn't strive to reduce it by making
> improvements to DMARC and possibly SPF.  One approach is to enable
> different senders to distinguish their differing levels of risk and
> infrastructure by letting them specify an "auth=" flag proposed on the 20th
> .
> For example a mom-and-pop sender on their own infrastructure with their own
> IPs will have a different profile than a risky, enterprise sender on shared
> IPs.  The former would be reasonably safe using SPF and would benefit most
> from using it.  The latter should use DKIM authentication only due to the
> risk of SPF upgrade spoofing and the phishing exposure.  I describe some
> additional ideas about how to use "auth=" flag with different risk and
> infrastructure stratification on the DKIM list on July 3rd (archive
>  /> ).
> 
> And FWIW I don't think mom-and-pop senders will find it that hard to adopt
> DKIM if sufficiently motivated.  For example for BIMI on Gmail, we now
> require DKIM-only authentication.  Indeed a new BIMI sender that I perceive
> to be running literally a "mom-and-pop" produce shop was using SPF
> authentication and was confused as to why their logo wasn't showing.  After
> explaining the requirement they were able to move to DKIM authentication in
> one day.  Yes, it did take explaining twice what was happening, but they
> were able to deploy DKIM on their own and got their logo to show up.
> 
> Also can we do more to harden SPF?  The SPF upgrade attacks needs three
> things:
> 
>- IPs shared by multiple sending domains
>- Some sender uses those IPs that permits spam and phish traffic
>- Those multiple sending domains have SPF policies that include those IPs
> 
> Perhaps one way to harden to SPF for DMARC is to detect if the IPs are
> shared.  The authenticator in addition to regular to SPF validation, might
> be able to use reverse PTR lookup and match the SPF record domain name (or
> match some subset like the org domain) to forward validate.  Only one
> domain can claim ownership for the IPs and be allowed to SPF authenticate
> for DMARC.
> 
> -Wei
> 
> On Mon, Jul 10, 2023 at 5:38 PM Scott Kitterman 
> 
> wrote:
> > I've been thinking about the thread on ditching SPF relative to DMARC.
> > 
> > DMARC is built on other protocols.  Piles of them.
> > 
> > DMARC is built most directly on DNS, DKIM, and SPF.  It is also built on
> > SMTP
> > and Email.  DKIM and SPF are also built on DNS and SMTP (SPF) or Email
> > (DKIM).
> > These protocols are built on others.  All of them have flaws and
> > limitations.
> > 
> > As an example, although each of the three 

Re: [dmarc-ietf] Protocols All The Way Down (long - sorry)

[Jan Dušátko]

Hi,
each mechanism approaches the problem in a different way:
- SPF authorizes selected hosts (machines approved to send mail)
- DKIM authenticates sender (proof of origin)
- ARC authenticate senders chain (also proof of origin, but also proof 
of whole communication chain)


we can also continue with other technologies, but this is not matter the 
DMARC story. For example S/MIME and GPG are from my perspective proof of 
will.


In a previous communication, I listed SPF as an obsolete technology. 
Also, this is matter of my perspective, due to problems in cloud systems 
where thousands of domains are on similar machines/address ranges. For 
this reason, SPF is currently limited in use, yet it still has its uses.


In a previous communication, I also reported on measurement statistics 
about saturation of specific technologies. These statistics are 
collected over domains. I will try to figure out the number of that 
domains, we did that analysis about one year ago. Total volume are about 
50 million e-mails per week. The problem with collecting this data is 
distribution across different mail systems on about 7000-8000 domains 
and another thousands of subdomains (oscillating in time).


From my point of view, the biggest problem at the moment is the 
protection of the sender's brand, i.e. the ability to unambiguously 
identify from which source the email originated and whether it was 
counterfeit (has been e-mail forged or not?). Current technologies such 
as SPF, DKIM and ARC, DMARC try to ensure this protection, but the owner 
is limited in deciding how he can allow his authentication. Since he is 
dependent on the correct implementation of these technologies by the 
recipient, he should be able to define his requirements. He cannot 
enforce them, but any problems due to the poor authentication of the 
sender then go to the recipient.


Regards

Jan

Dne 12. 7. 2023 v 3:18 Douglas Foster napsal(a):

So we disable SPF when the sender tells us to do so., but leave it enabled
by defaultThat makes a lot of sense to me.

When the domain passes SPF on a shared server farm, but provides no DKIM
signatures, I currently have no choice other than to consider the message
to be authenticated.  The AUTH token will provide that reason.

Hosting services could insist that senders configure DKIM, but that seems
to be a pipe dream.

Doug

On Tue, Jul 11, 2023, 8:50 PM Wei Chuang 
wrote:


The data we presented June 20th (archive
)
also suggests that it is premature to drop SPF from DMARC.  However I
differ in believing that we should accept the spoofing risk demonstrated
recently via SPF, and that we shouldn't strive to reduce it by making
improvements to DMARC and possibly SPF.  One approach is to enable
different senders to distinguish their differing levels of risk and
infrastructure by letting them specify an "auth=" flag proposed on the
20th
.
For example a mom-and-pop sender on their own infrastructure with their own
IPs will have a different profile than a risky, enterprise sender on shared
IPs.  The former would be reasonably safe using SPF and would benefit most
from using it.  The latter should use DKIM authentication only due to the
risk of SPF upgrade spoofing and the phishing exposure.  I describe some
additional ideas about how to use "auth=" flag with different risk and
infrastructure stratification on the DKIM list on July 3rd (archive

).

And FWIW I don't think mom-and-pop senders will find it that hard to adopt
DKIM if sufficiently motivated.  For example for BIMI on Gmail, we now
require DKIM-only authentication.  Indeed a new BIMI sender that I perceive
to be running literally a "mom-and-pop" produce shop was using SPF
authentication and was confused as to why their logo wasn't showing.  After
explaining the requirement they were able to move to DKIM authentication in
one day.  Yes, it did take explaining twice what was happening, but they
were able to deploy DKIM on their own and got their logo to show up.

Also can we do more to harden SPF?  The SPF upgrade attacks needs three
things:

- IPs shared by multiple sending domains
- Some sender uses those IPs that permits spam and phish traffic
- Those multiple sending domains have SPF policies that include those
IPs

Perhaps one way to harden to SPF for DMARC is to detect if the IPs are
shared.  The authenticator in addition to regular to SPF validation, might
be able to use reverse PTR lookup and match the SPF record domain name (or
match some subset like the org domain) to forward validate.  Only one
domain can claim ownership for the IPs and be allowed to SPF authenticate
for DMARC.

-Wei

On Mon, Jul 10, 2023 at 5:38 PM Scott Kitterman 
wrote:


I've been thinking about the thread on ditching SPF 

Re: [dmarc-ietf] Another p=reject text proposal

[Baptiste Carvello]

Hi,

Le 07/07/2023 à 23:58, John R Levine a écrit :
> 
> Why is it up to the recipient systems (the ones that do not care) to
> make life easier for lists?  Mailing list packages already do lots of
> analysis of bounce messages.  How about if they fix their bounce
> processing to recognize DMARC failures and do something different. 

Why? Because it's brittle and will only bring them more headaches? At
the very least, DMARC would need to use its own 5xy reply code to avoid
the need for parsing the reply text…

Or simply because they are *not* DMARC participants, and thus have no
reason to read this list? Standards usually serve to organize
interoperability between participants, not to inflict demands upon
unrelated third parties that they knowingly break.

That being said, maybe there is some simpler and better advice we can
give to mailing list operators who happen to listen: "If messages
bounce, first try to forcibly set the digest sending mode for this user.
If digests bounce too, then it's not DMARC, unsubscribe as usual". If
the mailing list software has a digest mode, implementation is
straightforward, and I can see no downsides compared to unsubscribe
right from the start.

Cheers,
Baptiste

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

Re: [dmarc-ietf] Another p=reject text proposal

[Baptiste Carvello]

Hi,

Le 08/07/2023 à 20:24, Scott Kitterman a écrit :
> 
> You can equally argue that these receivers are merely following the policy 
> advice provided by the sending domain (it has reject right in the name) and 
> this problem is entirely generated by sender's inappropriate use of p=reject.
> 
> I don't think engineering the location where the blame lands is the right 
> place to focus.  I've done plenty of blame avoidance engineering in my day, 
> but I don't think it's what the IETF should be doing.

This is not about blame avoidance. Blame avoidance is what happens right
now on this very list, with author domains and mail receivers first
blaming each other, then colluding to accuse absentee forwarders…

This is about avoiding the Tragedy of Commons where everyone waits for
the breakage to somehow solve itself (or, more cynically, for the victim
to resignate). The standard can help by clearly stating who has to act
in which circumstances. A MUST is better than a SHOULD, an it might well
be that two SHOULDs are worse than just one.

Cheers,
Baptiste

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

Re: [dmarc-ietf] Another p=reject text proposal

[Baptiste Carvello]

Hi,

Le 07/07/2023 à 21:09, Scott Kitterman a écrit :
> Doesn't sieve happen during delivery, after the message has been accepted?  
> Is so, I don't think it's a useful comparison to make.
> 
> The lack of bounce/rejection messages results in messages that vanish and 
> undermines the reliability of the email ecosystem.  I agree that silent 
> discard between MTAs is bad and we should not encourage it.

Please remember that "silent discard" is already proposed as a delivery
option in today's DMARCBis, section 8.3 (I wouldn't have dared to use
those words otherwise, I have principles too :-) ). But if it makes
people feel better, we can call it "delivery to user-inaccessible system
quarantine". We can even add that messages are not to be deleted from
said quarantine until the DMARC reports have been sent, so that no
message ever just "vanishes".

Rejecting at SMTP time also constrains the additional analysis that we
say Mail Receiver MUST do before rejecting, so deferred discard is bound
to become more common with DMARCBis anyway.

Also, maybe time has come to be pragmatic, as DMARC has been causing
breakage for 10 years already, all RFCs not withstanding. Bounces are
feedback sent to the wrong place, and bring no useful consequences. At
best they are ignored (which is just as sinful as not sending them), and
in the common worst case, they are misunderstood and break havoc.
Feedback to the right place (the author domain) happens through DMARC
reports.

On the benefit side, suppressing the risk of bounces avoids forcing the
mailing list operators to second-guess mail receivers and apply
problematic workarounds a priori. Recipients whose mail operator
correctly applies additional analysis can thus enjoy an unaltered
experience, which provides incentive. And recipients who lose messages
because their operator discards them can always elect to receive
digests, which are not impacted by DMARC.

Cheers,
Baptiste

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