Re: [dmarc-ietf] non-mailing list use case for differing header domains

[Jesse Thompson]

On 8/21/20 4:05 PM, Brandon Long wrote:
> 
> 
> On Fri, Aug 21, 2020 at 12:24 PM Jim Fenton  > wrote:
> 
> On 8/17/20 3:52 PM, Jesse Thompson wrote:
> > With a complex organization the only way to get people to change is to 
> publish a restrictive DMARC policy and then see who comes out of the woodwork 
> sheepishly admitting that they've been ignoring us for years. 
> >
> > Normal people sending email (especially those who are working with an 
> ESP, most of which happily send email without any DMARC alignment) do not 
> comprehend the notion that they should be using a subdomain for their 
> transactional messages; even when we directly communicate this fact to them 
> repeatedly.  They just don't understand the nuances of email.
> >
> I thought the DMARC reporting mechanism was there to allow such
> organizations to detect those behaviors and get them corrected without
> actually causing the damage of a restrictive policy.
> 
> 
> One thing we've found useful in this case is controlling the organization 
> from spamming.
> 
> Which is to say that the org has a policy on approvals and what is allowed to 
> be sent marketing wise, in some parts of the world to comply with laws on 
> such topics,
> or to be sure the entire org follows the principles and someone new doesn't 
> just poison the pool for everyone else.
> 
> There are always people who route around restrictions or sometimes don't even 
> bother to look for anything, they'll just hire a third party ESP and spam 
> away.
> 
> DMARC helps in this case to reduce the success of that and force them back to 
> internal compliance, which relieves the legal burden as well as the negative 
> impacts
> on delivery and public perception.
> 
> For folks who just register a new domain name and spam anyways... yeah, well, 
> there are other consequences down the line and other anti-phishing 
> restrictions that
> kick in at least on our inbound systems..

Right.  

Moving past p=none puts somewhat of a backstop on the internal compliance 
problem, which would otherwise continue indefinitely.  I've put them into a 
state where they have to get a subdomain and learn about DMARC.  

DMARC [aggregate] reports don't tell us *who* in our organization is 
perpetuating the problem, especially if their volume is low or not visible to 
the few DMARC reporters.  At some point you need to acknowledge that you will 
never have complete visibility.

Jesse

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

Re: [dmarc-ietf] non-mailing list use case for differing header domains

[Brandon Long]

On Fri, Aug 21, 2020 at 12:24 PM Jim Fenton  wrote:

> On 8/17/20 3:52 PM, Jesse Thompson wrote:
> > With a complex organization the only way to get people to change is to
> publish a restrictive DMARC policy and then see who comes out of the
> woodwork sheepishly admitting that they've been ignoring us for years.
> >
> > Normal people sending email (especially those who are working with an
> ESP, most of which happily send email without any DMARC alignment) do not
> comprehend the notion that they should be using a subdomain for their
> transactional messages; even when we directly communicate this fact to them
> repeatedly.  They just don't understand the nuances of email.
> >
> I thought the DMARC reporting mechanism was there to allow such
> organizations to detect those behaviors and get them corrected without
> actually causing the damage of a restrictive policy.
>

One thing we've found useful in this case is controlling the organization
from spamming.

Which is to say that the org has a policy on approvals and what is allowed
to be sent marketing wise, in some parts of the world to comply with laws
on such topics,
or to be sure the entire org follows the principles and someone new doesn't
just poison the pool for everyone else.

There are always people who route around restrictions or sometimes don't
even bother to look for anything, they'll just hire a third party ESP and
spam away.

DMARC helps in this case to reduce the success of that and force them back
to internal compliance, which relieves the legal burden as well as the
negative impacts
on delivery and public perception.

For folks who just register a new domain name and spam anyways... yeah,
well, there are other consequences down the line and other anti-phishing
restrictions that
kick in at least on our inbound systems..

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

Re: [dmarc-ietf] non-mailing list use case for differing header domains

[Jim Fenton]

On 8/17/20 3:52 PM, Jesse Thompson wrote:
> With a complex organization the only way to get people to change is to 
> publish a restrictive DMARC policy and then see who comes out of the woodwork 
> sheepishly admitting that they've been ignoring us for years.  
>
> Normal people sending email (especially those who are working with an ESP, 
> most of which happily send email without any DMARC alignment) do not 
> comprehend the notion that they should be using a subdomain for their 
> transactional messages; even when we directly communicate this fact to them 
> repeatedly.  They just don't understand the nuances of email.
>
I thought the DMARC reporting mechanism was there to allow such
organizations to detect those behaviors and get them corrected without
actually causing the damage of a restrictive policy.

-Jim

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

Re: [dmarc-ietf] non-mailing list use case for differing header domains

[Jesse Thompson]

On 8/7/20 9:32 PM, John Levine wrote:
>> We need spoofing protection for all of our domains without being told we're 
>> misdeploying.
>
> I would be interested to better undertstand the meaning of "need"
> here. It is my impression that most people vastly overestimate how
> much of a phish target they are. Paypal and big banks certainly are, 
> other places, a lot less so.

(Sorry, I was on a much-needed vacation.)

Ok, that's fair, I should have realized that one was over-stated.  *Need* would 
imply that domain-spoofing is more common than it is in reality.

Cybersecurity-minded folk in EDU tend to equate observed inbound phishing with 
spoofing (even though most phishing is spoofing the display name and message 
bodies, not the domain) and conclude that they *need* DMARC without really 
understanding the nuances.  Given the opportunity that DMARC marketing 
promises, they definitely *want* inbound DMARC enforcement for domain-spoofing 
of inbound mail (they'll defer to the email-minded folk to figure out the local 
policy exemptions, ARC, etc), as well as *want* domain policies that prevent 
the potential domain spoofing scenarios of owned domains (again, the 
email-minded folk will figure out how to actually "misdeploy" DMARC).  To them, 
it's just a checkmark towards some "maturity" benchmark that they use to 
compare to their peers.

Email-minded folk in EDU, knowing that DMARC doesn't really have much practical 
application to phishing, like having the observability that DMARC provides, as 
well as the hammer that moving past p=none provides as a way to coerce their 
complex, decentralized institution into a more sustainable operation: 

* Departments sending transactional email - move them to dedicated subdomains 
(this is where really complex institutions would benefit from walking the 
domain tree instead of always inheriting from the org domain)

* People sending user email from random places - move them to authenticated 
submission (preferably OAuth - since basic authentication is the reason why so 
many passwords are exposed)

The latter scenario is interesting because a single user sending from a random 
place doesn't really show up in DMARC aggregate reports.  It may show up in 
forensic reports, but it is easily lost in the noise.  (SPF macros might be 
another way to get fine-grained observability, but that's a privacy leakage 
IMO.)

In the end, it still results in:
* That person wouldn't end up on our radar for communication
* That person wouldn't understand what the message is about, even if we did 
communicate with them
* That person wouldn't comply, even if they understood
* Once enforcement is in place, that person will complain and leverage every 
ounce of their political influence to resist.  (It's really fun when your own 
users threaten lawsuits against you - that doesn't happen in Corporate IT.)

I'm kind of rambling now, I see.  Hope you find it enlightening, regardless!

Jesse

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

Re: [dmarc-ietf] non-mailing list use case for differing header domains

[Jesse Thompson]

On 8/13/20 10:03 AM, John R Levine wrote:
>> -Admittedly, that's where my bias comes in. My job is working with 
>> organizations that have paid my employer for me to be that outside help, so 
>> it's rare for me to see how badly it can be done by people setting 
>> restrictive DMARC policies without knowing what they're doing.
> 
> If they all talked to you first, we'd be having a very different discussion.

With a complex organization the only way to get people to change is to publish 
a restrictive DMARC policy and then see who comes out of the woodwork 
sheepishly admitting that they've been ignoring us for years.  

Normal people sending email (especially those who are working with an ESP, most 
of which happily send email without any DMARC alignment) do not comprehend the 
notion that they should be using a subdomain for their transactional messages; 
even when we directly communicate this fact to them repeatedly.  They just 
don't understand the nuances of email.

Similarly, it's only way to find all of the old DMARC-unaware MLMs, most of 
which haven't been security-patched for years.  Forcing them to upgrade to a 
MLM that can munge the From is a back-door way to get them to patch, or 
reassess their commitment to running the list in the first place.

Enterprise IT/cybersecurity actually want to get better manageability on the 
email their institution emit.  Misdeploying DMARC provides that.  Publishing 
restrictive DMARC on user domains is not always a clueless IT decision.

Jesse

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

Re: [dmarc-ietf] non-mailing list use case for differing header domains

[John R Levine]

-Admittedly, that's where my bias comes in. My job is working with 
organizations that have paid my employer for me to be that outside help, so 
it's rare for me to see how badly it can be done by people setting restrictive 
DMARC policies without knowing what they're doing.


If they all talked to you first, we'd be having a very different 
discussion.


Regards,
John Levine, jo...@taugh.com, Taughannock Networks, Trumansburg NY
Please consider the environment before reading this e-mail. https://jl.ly

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

Re: [dmarc-ietf] non-mailing list use case for differing header domains

[Autumn Tyr-Salvia]

"I do get the instinct to be proactive but if you’re going to be proactive, get 
ready to take the time and, if outside help needed, the money to do it without 
breaking legit mail."

-Admittedly, that's where my bias comes in. My job is working with 
organizations that have paid my employer for me to be that outside help, so 
it's rare for me to see how badly it can be done by people setting restrictive 
DMARC policies without knowing what they're doing.


Best,

Autumn Tyr-Salvia
atyrsal...@agari.com
Agari Principal Customer Success Engineer



From: Neil Anuskiewicz 
Sent: Wednesday, August 12, 2020 3:17 PM
To: John Levine 
Cc: dmarc@ietf.org ; Autumn Tyr-Salvia 
Subject: Re: [dmarc-ietf] non-mailing list use case for differing header domains



> On Aug 7, 2020, at 12:12 PM, John Levine  wrote:
>
> In article 
> 
>  you write:
>> I feel like what is happening sometimes is that central university IT is 
>> trying to drag their whole institutions into a
>> more secure posture before anybody in a position to stop them fully 
>> understands what's going on lest they be told to
>> stop because it might make things a little inconvenient.
>
> I was with you up until that sentence, since it trivializes the real
> problems that overly strict DMARC policies cause.
>
> Just yesterday I was sorting out a problem with people trying to
> finish editing a revised IETF standard about real-time web
> applications. Some of the authors' messages were disappearing,
> apparently at random. I saw what the problem was, one of the authors
> is at a big company whose IT department insists on p=reject (and has
> blown off complaints from fairly senior people about the problems it
> causes), the other uses an MIT alumni address that recently moved its
> hosting to Microsoft without telling anyone that the new host enforces
> DMARC policy while the old one didn't.
>
> My guess is that MIT figured Microsoft will host this for free, that's
> great, totally unaware that some of its users' mail would silently
> break.
>
> I told them as a workaround they needed to directly cc each other when
> they send anything to the group list, but the whole thing is a
> self-inflicted wound.
>
> R's,
> John
>
> ___
> dmarc mailing list
> dmarc@ietf.org
> https://nam12.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fdmarcdata=02%7C01%7Catyrsalvia%40agari.com%7C2388c4693f9a41d84d4308d83f0d7ab4%7C05773123385e420d844ef01aee5e37ab%7C0%7C0%7C637328674420006184sdata=u2xp7UMS7OHzkkyzHeoKa9Ri3w8v7sjJWvW%2BXuepmj4%3Dreserved=0

When mail breaks it’s more than an inconvenience. In business it can materially 
affect people’s livelihoods.

 I do think that sometimes people don’t take p=reject seriously enough, and 
don’t realize how much time and monitoring and prep it takes. I mostly work 
with smaller entities but I advise staying at  p=none of the time unless 
there’s spoofing. Otherwise, it’s reporting only, watch the reports, and take 
action if and only if there’s a problem.

I do get the instinct to be proactive but if you’re going to be proactive, get 
ready to take the time and, if outside help needed, the money to do it without 
breaking legit mail.
___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

Re: [dmarc-ietf] non-mailing list use case for differing header domains

[John R Levine]

I do think that sometimes people don’t take p=reject seriously enough, and 
don’t realize how much time and monitoring and prep it takes. I mostly work 
with smaller entities but I advise staying at  p=none of the time unless 
there’s spoofing. Otherwise, it’s reporting only, watch the reports, and take 
action if and only if there’s a problem.


Completely agree.  I have 240,000 aggregate and 80,000 failure reports in 
my database and I'm still publishing p=none for all my domains that 
actually send mail.


Regards,
John Levine, jo...@taugh.com, Taughannock Networks, Trumansburg NY
Please consider the environment before reading this e-mail. https://jl.ly___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

Re: [dmarc-ietf] non-mailing list use case for differing header domains

[Neil Anuskiewicz]

> On Aug 7, 2020, at 12:12 PM, John Levine  wrote:
> 
> In article 
> 
>  you write:
>> I feel like what is happening sometimes is that central university IT is 
>> trying to drag their whole institutions into a
>> more secure posture before anybody in a position to stop them fully 
>> understands what's going on lest they be told to
>> stop because it might make things a little inconvenient.
> 
> I was with you up until that sentence, since it trivializes the real
> problems that overly strict DMARC policies cause.
> 
> Just yesterday I was sorting out a problem with people trying to
> finish editing a revised IETF standard about real-time web
> applications. Some of the authors' messages were disappearing,
> apparently at random. I saw what the problem was, one of the authors
> is at a big company whose IT department insists on p=reject (and has
> blown off complaints from fairly senior people about the problems it
> causes), the other uses an MIT alumni address that recently moved its
> hosting to Microsoft without telling anyone that the new host enforces
> DMARC policy while the old one didn't.
> 
> My guess is that MIT figured Microsoft will host this for free, that's
> great, totally unaware that some of its users' mail would silently
> break.
> 
> I told them as a workaround they needed to directly cc each other when
> they send anything to the group list, but the whole thing is a
> self-inflicted wound.
> 
> R's,
> John
> 
> ___
> dmarc mailing list
> dmarc@ietf.org
> https://www.ietf.org/mailman/listinfo/dmarc

When mail breaks it’s more than an inconvenience. In business it can materially 
affect people’s livelihoods.

 I do think that sometimes people don’t take p=reject seriously enough, and 
don’t realize how much time and monitoring and prep it takes. I mostly work 
with smaller entities but I advise staying at  p=none of the time unless 
there’s spoofing. Otherwise, it’s reporting only, watch the reports, and take 
action if and only if there’s a problem. 

I do get the instinct to be proactive but if you’re going to be proactive, get 
ready to take the time and, if outside help needed, the money to do it without 
breaking legit mail. 
___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

Re: [dmarc-ietf] non-mailing list use case for differing header domains

[Douglas E. Foster]

Alessandro observed:
>>  However, that kind of hush hush is not deterministic, since the
>> protocol does not define the "external information". Providing for a
>> URL pointing to such external source might help.

Even an external reputation system requires recipient participation.   That is 
why I suggested both a send3="parameters" clause to indicate sender support for 
third-party authorization and a verify3="parameters" clause to indicate 
recipient support for third-party authentication.When both are visible to 
the non-domain message source, that source can have confidence that the message 
will be handled as authorized.

We have a very complete specification for ATSP signature delegation.
Do we have a similar document for your RHSWL approach?
Do we have a similar document for lookup into a trusted-forwarders list, 
assuming a service like that can be revived?

If ATSP and RHSWL solve essentially the same problem, we need to do an analysis 
of which is more likely to succeed, and proceed with that winner.

Third-party lookup is a very different approach than ATSP, so they can 
supplement each other.

DF


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

Re: [dmarc-ietf] non-mailing list use case for differing header domains

[Alessandro Vesely]

On 2020-08-09 6:54 p.m., Tõnu Tammer wrote:


DMARC relies on SPF and DKIM. The latter is particularly important for
the mailing lists to ensure that DMARC works. And when I read the cases
it is clear that the issue is not of DMARC but of DKIM.



Indeed, one of the proposed workarounds, Recognized Transformations of 
Messages, addresses DKIM verification algorithm.  Yet, it is being 
discussed on this list rather than ietf-dkim.  I hope it becomes a WG 
draft soon.




RFC for DKIM says very clearly in the introductory part that and I
quote "Message transit from author to recipient is through relays
that typically make no substantive change to the message content
and thus preserve the DKIM signature." If this is not the case, the
relay is actually violating DKIM standard.


As Dave said, MLMs may need to carry out some transformations while 
usual relays don't —except those which add **SPAM** subject tags or 
antivirus footers.


The l= tag is one of the early envisaged provisions to address footer 
additions.  It was deprecated because of the possibility to add 
malicious footers.  Of course, adding a footer /is/ a substantive change.


However tight we define recognized transformations, they have to allow 
the addition of a few lines and a URL.  Hence, they can be malicious. 
 Therefore, we need to differentiate two classes of domain owners, 
those who can afford such risk and those who want top strictness.




The lists we manage, we have made sure they follow the RFC and there is
no issue of DKIM preservation.



https://wiki.asrg.sp.am/wiki/Mitigating_DMARC_damage_to_third_party_mail#Turn_off_all_message_modifications



Some lists, however, have taken a different approach and to make
sure we have delivery there also, we've looked at the elements
which are used for DKIM calculation. We realise that not including
the content into hash calculation can have a drawback but given
that non-DKIM compliant lists do with content what they wish 
anyway, it's not much of a drawback. At the same time, prevention 
against spoofing and misuse is retained, which is the key for

DMARC.



That only works if you trust the MLM.  We cannot rely on trust, 
because there is no widespread common reputation system.  DMARC does 
provide for "trusted_forwarder" and "mailing_list" policy override types:


   However, before this action is taken, the Mail Receiver can consult
   external information to override the Domain Owner's policy.  For
   example, if the Mail Receiver knows that this particular email came
   from a known and trusted forwarder (that happens to break both SPF
   and DKIM), then the Mail Receiver may choose to ignore the Domain
   Owner's policy.

However, that kind of hush hush is not deterministic, since the 
protocol does not define the "external information".  Providing for a 
URL pointing to such external source might help.



Best
Ale
--





















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

Re: [dmarc-ietf] non-mailing list use case for differing header domains

[Jim Fenton]

On 8/5/20 9:36 AM, Jesse Thompson wrote:
> On 8/4/20 11:52 AM, Alessandro Vesely wrote:
>> On 2020-08-04 6:10 p.m., Dotzero wrote:
>>> There is another solution. Move users to a separate domain from the domain
> Long ago we put users on our org domain as a way to unify users (in a very 
> decentralized institution) under a single domain identity, and that branding 
> decision is not going to be undone, politically.  Any project to move users 
> from one domain identity to another is a huge lift; it takes a lot of time, 
> effort, and never actually completes due to stragglers with very legitimate 
> reasons to not give up sending from their old address.  
>
> I think that end-users would rather see their list mail be rewritten than be 
> told to change their identity.  I know that some people on this list think 
> that the domain in the from header isn't commonly visible anymore, but the 
> domain is extremely important to users' sense of identity.

>>> your transactional mails are sent from. You can also put users on a
>>> separate subdomain.


You really don't want to move users; they would need to notify all of
their correspondents. Instead, leave the users where they are and move
the transactional mail to a different domain (or to a subdomain) and put
the restrictive policy there.

-Jim


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

Re: [dmarc-ietf] non-mailing list use case for differing header domains

[Dave Crocker]

On 8/9/2020 9:54 AM, Tõnu Tammer wrote:

"Message
transit from author to recipient is through relays that typically make
no substantive change to the message content and thus preserve the DKIM
signature." If this is not the case, the relay is actually violating
DKIM standard.


However, a mailing list is not a 'relay'.  The term relay is meant to 
refer to an MTA.


Reviewing RFC 5598 might help.

d/

--
Dave Crocker
Brandenburg InternetWorking
bbiw.net

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

Re: [dmarc-ietf] non-mailing list use case for differing header domains

[Tõnu Tammer]

Hi!

I keep reading the discussion and I am surprised how people express
views that current DMARC standard does not work. I am surprised that
technical people here express this view.

DMARC relies on SPF and DKIM. The latter is particularly important for
the mailing lists to ensure that DMARC works. And when I read the cases
it is clear that the issue is not of DMARC but of DKIM. RFC for DKIM
says very clearly in the introductory part that and I quote "Message
transit from author to recipient is through relays that typically make
no substantive change to the message content and thus preserve the DKIM
signature." If this is not the case, the relay is actually violating
DKIM standard.

The lists we manage, we have made sure they follow the RFC and there is
no issue of DKIM preservation. Some lists, however, have taken a
different approach and to make sure we have delivery there also, we've
looked at the elements which are used for DKIM calculation. We realise
that not including the content into hash calculation can have a drawback
but given that non-DKIM compliant lists do with content what they wish
anyway, it's not much of a drawback. At the same time, prevention
against spoofing and misuse is retained, which is the key for DMARC.

Tonu
t...@cert.ee

On 09.08.2020 18:11, Hannu Aronsson wrote:
> Hello,
>
> Quick correction: As DMARC requires only either DKIM or SPF which I had 
> confused, this removes the need for the proposal point 1). Thanks for the 
> off-list help received.
>
> This seems to be mostly an SPF issue, but still remains when
> - SPF used used alone without DMARC (not sure if relevant for this 
> discussion, but it is a real-world problem) and 
> - DMARC when DKIM is not used and it falls back to SPF
> causing indirect emails to fail, especially with p=reject or -all settings or 
> overly strict receiver deployments. 
>
> For fixing the SPF issue a solution using ARC would be much preferable to the 
> SRS (Sender Rewriting Scheme) workaround, because e.g. the messages would be 
> unchanged, avoid problems with long email addresses or requiring databases, 
> and DMARC strict From alignment issues, etc.
>
> The other topics in the email, 
> - forwarding use cases from M3AAWG discussions and 
> - figuring out how we could get ARC reputation solution in place
> are hopefully still interesting for this discussion.
>
> Yours,
>   Hannu
>
>> On 9.8.2020, at 13:28+0300, Hannu Aronsson  wrote:
>>
>> Hello,
>>
>> I have been lurking here around for a while and we have been working at 
>> M3AAWG for some time as well.
>>
>> Today’s DMARC is breaking more and more email as it gets more widely and 
>> often overly strictly deployed.
>>
>> I feel the major issue with DMARC is email forwarding in it’s many forms, in 
>> addition to mailing list issues. It would be preferable to try to do 
>> something that helps email survive as an open platform instead of bad 
>> workarounds. 
>>
>> Transactional and person-to-person emails also should work reliably with 
>> DMARC (and similar things) when forwarded i.e. indirect delivery.
>>
>>
>> In M3AAWG discussions, we have identified many stakeholders who are seeing 
>> major issues with DMARC and SPF when forwarding email for various valid 
>> reasons, examples:
>>
>> a) ISPs hosting user domains and email from to addresses in those domains is 
>> forwarded to external mailbox addresses. This is very common for smaller 
>> organizations.
>>
>> b) Alumni and organization member addresses like alumni.harvard.edu, 
>> acm.org, iki.fi and many others that provide a “permanent” email address and 
>> forward email to user-specified mailbox provider addresses.
>>
>> c) Users forwarding email themselves to another email address e.g. based on 
>> rules or forwarding to their mobile device address, or forwarding old ISP 
>> email to new ISP, etc.
>>
>> d) Some mailing lists and smaller email distributions, too, which work just 
>> forward messages as they are to their members.
>>
>> e) and of course the many users using these services, and senders trying to 
>> send to them.
>>
>> So there may be many more stakeholders with DMARC issues than one might 
>> initially think about. DMARC is creating a lot of “the message did not get 
>> thru” issues for valid and real emails these days.
>>
>> To be worth pushing further, DMARC needs to be compatible with with email 
>> forwarding i.e. indirect mail flows.
>>
>>
>> To try to clarify my thinking around this, I tried to put some thoughts into 
>> a practical proposal format so it would be easier to consider, comment and 
>> discuss and think about the practicalities around it.
>>
>> Based on the discussion, it seems it might be more practical to try to make 
>> “small” improvements into DMARC. If we can find some useful way forward, 
>> we’re willing to work on an internet-draft for more formal commenting.
>>
>> Background, in addition to the use cases above:
>>
>> Because SPF fails with forwarded/indirect emails, and as DMARC 

Re: [dmarc-ietf] non-mailing list use case for differing header domains

[Hannu Aronsson]

Hello,

Quick correction: As DMARC requires only either DKIM or SPF which I had 
confused, this removes the need for the proposal point 1). Thanks for the 
off-list help received.

This seems to be mostly an SPF issue, but still remains when
- SPF used used alone without DMARC (not sure if relevant for this discussion, 
but it is a real-world problem) and 
- DMARC when DKIM is not used and it falls back to SPF
causing indirect emails to fail, especially with p=reject or -all settings or 
overly strict receiver deployments. 

For fixing the SPF issue a solution using ARC would be much preferable to the 
SRS (Sender Rewriting Scheme) workaround, because e.g. the messages would be 
unchanged, avoid problems with long email addresses or requiring databases, and 
DMARC strict From alignment issues, etc.

The other topics in the email, 
- forwarding use cases from M3AAWG discussions and 
- figuring out how we could get ARC reputation solution in place
are hopefully still interesting for this discussion.

Yours,
  Hannu

> On 9.8.2020, at 13:28+0300, Hannu Aronsson  wrote:
> 
> Hello,
> 
> I have been lurking here around for a while and we have been working at 
> M3AAWG for some time as well.
> 
> Today’s DMARC is breaking more and more email as it gets more widely and 
> often overly strictly deployed.
> 
> I feel the major issue with DMARC is email forwarding in it’s many forms, in 
> addition to mailing list issues. It would be preferable to try to do 
> something that helps email survive as an open platform instead of bad 
> workarounds. 
> 
> Transactional and person-to-person emails also should work reliably with 
> DMARC (and similar things) when forwarded i.e. indirect delivery.
> 
> 
> In M3AAWG discussions, we have identified many stakeholders who are seeing 
> major issues with DMARC and SPF when forwarding email for various valid 
> reasons, examples:
> 
> a) ISPs hosting user domains and email from to addresses in those domains is 
> forwarded to external mailbox addresses. This is very common for smaller 
> organizations.
> 
> b) Alumni and organization member addresses like alumni.harvard.edu, acm.org, 
> iki.fi and many others that provide a “permanent” email address and forward 
> email to user-specified mailbox provider addresses.
> 
> c) Users forwarding email themselves to another email address e.g. based on 
> rules or forwarding to their mobile device address, or forwarding old ISP 
> email to new ISP, etc.
> 
> d) Some mailing lists and smaller email distributions, too, which work just 
> forward messages as they are to their members.
> 
> e) and of course the many users using these services, and senders trying to 
> send to them.
> 
> So there may be many more stakeholders with DMARC issues than one might 
> initially think about. DMARC is creating a lot of “the message did not get 
> thru” issues for valid and real emails these days.
> 
> To be worth pushing further, DMARC needs to be compatible with with email 
> forwarding i.e. indirect mail flows.
> 
> 
> To try to clarify my thinking around this, I tried to put some thoughts into 
> a practical proposal format so it would be easier to consider, comment and 
> discuss and think about the practicalities around it.
> 
> Based on the discussion, it seems it might be more practical to try to make 
> “small” improvements into DMARC. If we can find some useful way forward, 
> we’re willing to work on an internet-draft for more formal commenting.
> 
> Background, in addition to the use cases above:
> 
> Because SPF fails with forwarded/indirect emails, and as DMARC today depends 
> on SPF, it also fails in these use cases, especially when deployed overly 
> strictly.
> 
> Normal email forwarding does not break DKIM as the messages are not changed. 
> We have new tools available today that can help, specifically ARC.
> 
> We should aim to make DMARC compatible with these forwarding use cases, 
> without losing the anti-abuse aims if possible.
> 
> Draft proposal for comments: 
> 
> When a DMARC recipient MTA is processing an incoming message,
> 
> 1) If DKIM is valid, SPF results should be ignored. DKIM already proves the 
> message is from the source it claims to be from, it doesn’t matter if it 
> arrived via an indirect path.
> 
> 2) If DKIM is not used, but ARC is used, SPF processing should walk the ARC 
> header chain as long as they have acceptable reputation and if a matching IP 
> address is found there, consider the SPF check successful.
> 
> 3) If DKIM and ARC are not used and SPF/DMARC fails, you could act as today, 
> or probably we should recommend always putting failing messages somewhere 
> where the user can search for the “lost messages” when needed, e.g. to the 
> junk mailbox or quarantine.
> 
> If something like this was in place, forwarders and others would be highly 
> motivated to implement ARC, helping senders and recipients who want to deploy 
> DMARC or DMARC-like solutions.
> 
> ARC reputation:
> 
> ARC reputation 

Re: [dmarc-ietf] non-mailing list use case for differing header domains

[Hannu Aronsson]

Hello,

I have been lurking here around for a while and we have been working at M3AAWG 
for some time as well.

Today’s DMARC is breaking more and more email as it gets more widely and often 
overly strictly deployed.

I feel the major issue with DMARC is email forwarding in it’s many forms, in 
addition to mailing list issues. It would be preferable to try to do something 
that helps email survive as an open platform instead of bad workarounds. 

Transactional and person-to-person emails also should work reliably with DMARC 
(and similar things) when forwarded i.e. indirect delivery.


In M3AAWG discussions, we have identified many stakeholders who are seeing 
major issues with DMARC and SPF when forwarding email for various valid 
reasons, examples:

a) ISPs hosting user domains and email from to addresses in those domains is 
forwarded to external mailbox addresses. This is very common for smaller 
organizations.

b) Alumni and organization member addresses like alumni.harvard.edu, acm.org, 
iki.fi and many others that provide a “permanent” email address and forward 
email to user-specified mailbox provider addresses.

c) Users forwarding email themselves to another email address e.g. based on 
rules or forwarding to their mobile device address, or forwarding old ISP email 
to new ISP, etc.

d) Some mailing lists and smaller email distributions, too, which work just 
forward messages as they are to their members.

e) and of course the many users using these services, and senders trying to 
send to them.

So there may be many more stakeholders with DMARC issues than one might 
initially think about. DMARC is creating a lot of “the message did not get 
thru” issues for valid and real emails these days.

To be worth pushing further, DMARC needs to be compatible with with email 
forwarding i.e. indirect mail flows.


To try to clarify my thinking around this, I tried to put some thoughts into a 
practical proposal format so it would be easier to consider, comment and 
discuss and think about the practicalities around it.

Based on the discussion, it seems it might be more practical to try to make 
“small” improvements into DMARC. If we can find some useful way forward, we’re 
willing to work on an internet-draft for more formal commenting.

Background, in addition to the use cases above:

Because SPF fails with forwarded/indirect emails, and as DMARC today depends on 
SPF, it also fails in these use cases, especially when deployed overly strictly.

Normal email forwarding does not break DKIM as the messages are not changed. We 
have new tools available today that can help, specifically ARC.

We should aim to make DMARC compatible with these forwarding use cases, without 
losing the anti-abuse aims if possible.

Draft proposal for comments: 

When a DMARC recipient MTA is processing an incoming message,

1) If DKIM is valid, SPF results should be ignored. DKIM already proves the 
message is from the source it claims to be from, it doesn’t matter if it 
arrived via an indirect path.

2) If DKIM is not used, but ARC is used, SPF processing should walk the ARC 
header chain as long as they have acceptable reputation and if a matching IP 
address is found there, consider the SPF check successful.

3) If DKIM and ARC are not used and SPF/DMARC fails, you could act as today, or 
probably we should recommend always putting failing messages somewhere where 
the user can search for the “lost messages” when needed, e.g. to the junk 
mailbox or quarantine.

If something like this was in place, forwarders and others would be highly 
motivated to implement ARC, helping senders and recipients who want to deploy 
DMARC or DMARC-like solutions.

ARC reputation:

ARC reputation has been discussed a lot and may be a major roadblock in going 
this way. I think the situation has changed now as DMARC issues become larger 
and affect more users, so people are more ready to do something about it now.

* Technically we should be able to simply use DNS-based IP allowlists to get 
reputation information for the ARC signing intermediaries.

* ARC allowlisting would allows MTA admins to choose suitable allowlists from 
free and paid options from various sources and vendors, just like they use 
blocklists today for email already. 

* We could probably even re-use existing email RBL allow/blocklists for this 
purpose, if you don’t trust some IP reputation as sender, you would not trust 
it for ARC either.

* Free options would be available so DMARC2 software and solutions could 
include default settings that already work out of the box for smaller 
organizations.  

* It seems possible to maintain semi-manual lists of “major trusted” forwarding 
services and have a suitable vetting process for that. At iki.fi we have looked 
at doing something like this, if it would help.

* Additionally people would offer various automated lists based on other 
analysis and methods.

* ARC reputation could at this time have become an additional service 

Re: [dmarc-ietf] non-mailing list use case for differing header domains

[Douglas E. Foster]

The unifying principle is that we need a third-party authentication method, a 
need which is not adequately satisfied with SPF and DKIM.   The standard can 
support multiple options, such as the following

send3="method=ATPS,p=reject,sp=quarantine;  
method=reputation,p=quarantine,dns=uri; method=RHSWL, sp=reject"

where:
"method=ATPS" means RFC 6541 third-party signatures, as suggested by 
Hector"method=reputation" means a trust service like trusted-forwarders.org, as 
suggested by John"method=RHSWL" means the whitelist system suggested by 
Alessandro
Usage:
If multiple methods are specified, the receiver checks all of the methods that 
it is willing and able to use.If p= is missing, the third-party authentication 
method is not supported for primary domains.If sp= is missing, the third-party 
verification method is not supported for subdomainsIf any method passes, the 
message passes.   No other checks need to be performed.   If all methods fail, 
the strictest policy is the recommendation action.If any third-party 
authorization method is supported, the DMARC policies should be p=none and 
sp=none, to avoid false positives by entities that do not know how to check the 
third-party method.
A domain could optionally advertise which third-party methods it is willing to 
check using a similar keyword structure:
verify3="method ATPS;  method=reputation; dns=uri; method=RHSWL".
This would allow senders to limit third-party impersonation to those recipients 
that will accept the impersonation as legitimate.

It would be desirable for DMARC feedback reports to indicate which third-party 
methods were checked.   Updating the reporting specification might be more 
complex than specifying the verification method itself.

Do we move forward with an approach like this?


From: Alessandro Vesely 
Sent: 8/8/20 5:52 AM
To: dmarc@ietf.org
Subject: Re: [dmarc-ietf] non-mailing list use case for differing header domains
On 2020-08-08 4:27 a.m., John Levine wrote:
>
> Some years back people kept asking Spamhaus to set up a whitelist, so
> they hired me to do it. Technically it worked fine, but it soon became
> apparent that the only people who were interested weren't people who
> we'd want to whitelist. The good quality senders get their mail
> delivered already, the terrible ones didn't bother, and all we heard
> from were people who sometimes sent some spam along with the good mail
> but assured us they were nice people.

I'm not clear why that failed. Personally, I was puzzled by the .com
suffix, which somehow sounded like pay for being whitelisted.

> I think you'll find that all of the existing whitelist like things
> are a sideshow to the company's real business of deliverability
> consulting.

Of course whitelisting can easily become ESPs combat zone.

> For DMARC, it would be nice if there were a shared list of credible
> forwarders, not to automatically accept their mail, but just to say
> they're good enough that you can believe what's in their ARC seals
> when you're doing the usual spam filtering.

Trusted-forwarder.org still exists...[*]

Automatically accept is not the same as override DMARC policy. The
latter can cure some of MLM and non-MLM problems.

I proposed snd=rhswl.zone.example. The difference w.r.t.
trusted-forwarder.org is that some sites can start building their own
right hand side whitelists (RHSWL). Specifying the zone in the
protocol makes it visible, so lazy admins can help themselves to
quickly build their not-so-strict DMARC policy by using someone else's
RHSWL.

Combining lists could also become possible, once there is a decent
amount of them. There is already An Architecture for Reputation
Reporting, RFC 7070/3, which could support exchanging entries among
similarly scoped RHSWLs.

> You can't just let people sign themselves up for a list like that,
> since every dodgy bulk mailer will figure this will get them an
> extra 2% delivery, and we've never gotten past a vague hope that we
> could canvass people we know to make a combined set of mailing
> lists hosts we know.

Seeking how to make that hope less vague should be a highly commended
task.

Best
Ale
--

[*] http://multirbl.valli.org/detail/wl.trusted-forwarder.org.html

___
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] non-mailing list use case for differing header domains

[Alessandro Vesely]

On 2020-08-08 4:27 a.m., John Levine wrote:


Some years back people kept asking Spamhaus to set up a whitelist, so
they hired me to do it. Technically it worked fine, but it soon became
apparent that the only people who were interested weren't people who
we'd want to whitelist. The good quality senders get their mail
delivered already, the terrible ones didn't bother, and all we heard
from were people who sometimes sent some spam along with the good mail
but assured us they were nice people.



I'm not clear why that failed.  Personally, I was puzzled by the .com 
suffix, which somehow sounded like pay for being whitelisted.




I think you'll find that all of the existing whitelist like things
are a sideshow to the company's real business of deliverability
consulting.


Of course whitelisting can easily become ESPs combat zone.



For DMARC, it would be nice if there were a shared list of credible
forwarders, not to automatically accept their mail, but just to say
they're good enough that you can believe what's in their ARC seals
when you're doing the usual spam filtering.



Trusted-forwarder.org still exists...[*]

Automatically accept is not the same as override DMARC policy.  The 
latter can cure some of MLM and non-MLM problems.


I proposed snd=rhswl.zone.example.  The difference w.r.t. 
trusted-forwarder.org is that some sites can start building their own 
right hand side whitelists (RHSWL).  Specifying the zone in the 
protocol makes it visible, so lazy admins can help themselves to 
quickly build their not-so-strict DMARC policy by using someone else's 
RHSWL.


Combining lists could also become possible, once there is a decent 
amount of them.  There is already An Architecture for Reputation 
Reporting, RFC 7070/3, which could support exchanging entries among 
similarly scoped RHSWLs.




You can't just let people sign themselves up for a list like that,
since every dodgy bulk mailer will figure this will get them an
extra 2% delivery, and we've never gotten past a vague hope that we
could canvass people we know to make a combined set of mailing
lists hosts we know.


Seeking how to make that hope less vague should be a highly commended 
task.



Best
Ale
--

[*] http://multirbl.valli.org/detail/wl.trusted-forwarder.org.html



























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

Re: [dmarc-ietf] non-mailing list use case for differing header domains

[Dave Crocker]

On 8/7/2020 7:32 PM, John Levine wrote:

I would be interested to better undertstand the meaning of "need"
here. It is my impression that most people vastly overestimate how
much of a phish target they are. Paypal and big banks certainly are,
other places, a lot less so.



I suspect the calculus is less in the pragmatic terms of asking how big 
this threat is and more in terms of wishing for some version of 
protection and thinking this helps to achieve it.


The degree to which so many folk embrace does not appear to have that 
much empirical basis, but rather a sense of feeling a need to do 
something and at first blush this seems to be something.


d/

--
Dave Crocker
Brandenburg InternetWorking
bbiw.net

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

Re: [dmarc-ietf] non-mailing list use case for differing header domains

[John Levine]

In article <78fd8b26-0bed-ac36-842d-a851ec04d...@wisc.edu> you write:
>On 8/7/20 2:12 PM, John Levine wrote:
>> My guess is that MIT figured Microsoft will host this for free, that's
>> great, totally unaware that some of its users' mail would silently
>> break.
>
>Customers of Microsoft don't like to call things bundled in an expensive 
>package "free".

I have no idea what their pricing ie. My university uses Gmail for the
alumni service and I believe that actually is free.

>Maybe it was inflicted by the domain owner onto the person maintaining the 
>mailing list.  (In my experience, this is
>where people realize that no one has been maintaining/patching the mailing 
>list, unaware of DMARC, etc.)

The IETF is entirely aware of DMARC, and their main mailing lists use
a version of my dmarc.fail hack. This one's off in a corner, on the list of 
things
to be cleaned up.

>My peeve in recent years is that universities were essentially coerced 
>(economically) into being the customers of
>Microsoft/Google and then the email admins are told to sit down and let the 
>adults talk about what they think customers
>need from DMARC, ARC, etc.  It's why I'm constantly sticking my foot in my 
>mouth here and M3AAWG; trying to assert a
>voice.

If it's not obvious, we do appreciate it.  Way too many of them say whew, we 
can blame the vendor
and not worry about it.

>We need faculty/alumni/emeriti forwarding to work without being told that 
>Microsoft can't do it without breaking DMARC.

Yup.

>We need spoofing protection for all of our domains without being told we're 
>misdeploying.

I would be interested to better undertstand the meaning of "need"
here. It is my impression that most people vastly overestimate how
much of a phish target they are. Paypal and big banks certainly are, 
other places, a lot less so.

R's,
John

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

Re: [dmarc-ietf] non-mailing list use case for differing header domains

[John Levine]

In article <10c441a53dec4277a3153ed8d89d3...@bayviewphysicians.com> you write:
>-=-=-=-=-=-
>
>Murray, I  have most recently used this link at AOL/Yahoo:  
>https://postmaster.verizonmedia.com/sender-request 
>
>I have considered using the more complete "Complaint Feedback Loop", 
>https://postmaster.verizonmedia.com/cfl-request 
>but have never completed the process.

Complaint feedback loops just mean you say (perhaps with verification)
that you're the contact for this range of IPs or domain names, and if
a user presses the Junk button, the system can send you a copy of the
report. It's not whitelisting, and it only covers about the first
quarter inch of the long tail.

Some years back people kept asking Spamhaus to set up a whitelist, so
they hired me to do it. Technically it worked fine, but it soon became
apparent that the only people who were interested weren't people who
we'd want to whitelist. The good quality senders get their mail
delivered already, the terrible ones didn't bother, and all we heard
from were people who sometimes sent some spam along with the good mail
but assured us they were nice people. (Many universities fall into
this category.) I think you'll find that all of the existing whitelist
like things are a sideshow to the company's real business of
deliverability consulting.

For DMARC, it would be nice if there were a shared list of credible
forwarders, not to automatically accept their mail, but just to say
they're good enough that you can believe what's in their ARC seals
when you're doing the usual spam filtering. You can't just let people
sign themselves up for a list like that, since every dodgy bulk mailer
will figure this will get them an extra 2% delivery, and we've never
gotten past a vague hope that we could canvass people we know to make
a combined set of mailing lists hosts we know.

R's,
John

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

Re: [dmarc-ietf] non-mailing list use case for differing header domains

[Douglas E. Foster]

Murray, I  have most recently used this link at AOL/Yahoo:  
https://postmaster.verizonmedia.com/sender-request

I have considered using the more complete "Complaint Feedback Loop", 
https://postmaster.verizonmedia.com/cfl-request  but have never completed the 
process.

Maybe they are the last to offer this type of feature.  Or maybe my memory is 
imagining things   Now that you have pressed me, I cannot remember whether I 
have had success with other services or not.

My heart is not in prior registration either, but I was trying to lay out the 
next-best alternative for those who want an alternative to using the MLM domain 
identity.

The goal of DMARC is to end spoofing, which requires everyone to send using 
their own domain, even when performing a favor for someone in another domain.   
A recipient domain owner has the right to define the rules for getting into its 
network.Those who want into that network should play by the rules of that 
network, whether the rules are liked or disliked.

An incoming email is a take-it-or-leave-it proposition for most recipients.   
My domain does not have the market power to alter sender behavior.   When I 
receive a spoofed message that the recipient actually wants, I end up creating 
an exception to allow the spoof.   Spoofing senders are counting on their 
ability to force me to do that.   However, Microsoft is powerful enough to 
engage in a standoff.Those who want to send to Microsoft destinations will 
need to not violate DMARC.   I hope and expect that they will win this battle.

DMARC is not new.   Products that have not become DMARC-aware are as obsolete 
as WindowsXP.   Unfortunately, that does include a lot of products.

Over a year ago, I was about to recommend Proofpoint as our new email filtering 
vendor.   But the next morning I realized that their secure email service will 
spoof the identity of non-clients when they respond to a message from a client. 
  I had a real problem with a vendor promoting their ability to enforce DMARC 
on incoming mail, while also violating DMARC on their secure email service.   
Then I saw that Cisco Ironport did the same thing.   I raised CIRT issues with 
both vendors, but nothing has changed.   Maybe Microsoft will be able to change 
their attitudes.
DF


From: "Murray S. Kucherawy" 
Sent: 8/7/20 7:16 PM
To: Doug Foster 
Cc: Dave Crocker , IETF DMARC WG 
Subject: Re: [dmarc-ietf] non-mailing list use case for differing header domains
On Sun, Aug 2, 2020 at 5:44 PM Douglas E. Foster 
 wrote:
Murray took server too literally.   I have expressed before that a system could 
do a sender authentication lookup on List-ID as easily as on From.   In this 
respect, it is similar to Dave's proposal, without the added complexity of 
additional identifiers.   So think "Registerd List-ID plus DKIM signature (or 
SPF, but DKIM seems both sufficient and preferable.)

If we take "server" to mean a tuple made up of a List-ID value and a "d=" value 
from a validated DKIM signature, which I believe is what you're saying here, 
the first occurrence of this necessarily has no internal value (or history) 
attached to it.  That means the operator has to develop meaning for it over 
time, which doesn't tell it how to handle the first N such messages.  Err on 
the side of openness and you have a spam or attack vector; err on the side of 
defense and you irritate your users by denying them some list traffic until a 
reputation can develop.

And it's probably actually a three-tuple, with the third part being the 
recipient.  Otherwise, I could register (or trigger the auto-registration of) 
any two-tuple I want and thus intentionally let in my preferred list streams, 
good or bad, which affects every other user.

Plus, you're trusting users to get this right.  For a manual registration 
scheme, every time they get it wrong by entering the wrong data or failing to 
even do it at all, you've got a failure mode to deal with, usually in the form 
of user complaints which require other humans to resolve.  That makes it 
relatively expensive.

And finally, lists change once in a while, maybe to a new signing domain, maybe 
to a new name, maybe both.  Every time that happens, the process has to start 
over.  Naturally lists won't want to do this because of the sterling 
reputations they've developed, but the pain reappears whenever the process 
needs to be repeated for whatever reason.

I'm not saying such a system can't or won't work.  I'm also not saying I have a 
better idea.  I am saying there's multi-faceted pain in every direction in this 
space, and this is no exception.  Whatever path we choose to deploy here has to 
account for those choices and their side effects, and the ways they might be 
gamed.

I am not sure what "Internet Scale" means to you.   Most of the major 
recipients have bulk mailer registration systems.   It does not guara

Re: [dmarc-ietf] non-mailing list use case for differing header domains

[Jesse Thompson]

On 8/7/20 2:12 PM, John Levine wrote:
> In article 
> 
>  you write:
>> I feel like what is happening sometimes is that central university IT is 
>> trying to drag their whole institutions into a
>> more secure posture before anybody in a position to stop them fully 
>> understands what's going on lest they be told to
>> stop because it might make things a little inconvenient.
> 
> I was with you up until that sentence, since it trivializes the real
> problems that overly strict DMARC policies cause.

Maybe Autumn was reflecting the reality that the industry has already 
trivialized DMARC problems for these "misdeployments".  

 
> Just yesterday I was sorting out a problem with people trying to
> finish editing a revised IETF standard about real-time web
> applications. Some of the authors' messages were disappearing,
> apparently at random. I saw what the problem was, one of the authors
> is at a big company whose IT department insists on p=reject (and has
> blown off complaints from fairly senior people about the problems it
> causes), the other uses an MIT alumni address that recently moved its
> hosting to Microsoft without telling anyone that the new host enforces
> DMARC policy while the old one didn't.
> 
> My guess is that MIT figured Microsoft will host this for free, that's
> great, totally unaware that some of its users' mail would silently
> break.

Customers of Microsoft don't like to call things bundled in an expensive 
package "free".

My peeve in recent years is that universities were essentially coerced 
(economically) into being the customers of Microsoft/Google and then the email 
admins are told to sit down and let the adults talk about what they think 
customers need from DMARC, ARC, etc.  It's why I'm constantly sticking my foot 
in my mouth here and M3AAWG; trying to assert a voice.

We need faculty/alumni/emeriti forwarding to work without being told that 
Microsoft can't do it without breaking DMARC.

We need spoofing protection for all of our domains without being told we're 
misdeploying.

We know that we need advanced local policy controls for DMARC enforcement and 
we don't want to be blamed when the vendor doesn't give us those controls (to 
your MIT example) 


> I told them as a workaround they needed to directly cc each other when
> they send anything to the group list, but the whole thing is a
> self-inflicted wound.

Maybe it was inflicted by the domain owner onto the person maintaining the 
mailing list.  (In my experience, this is where people realize that no one has 
been maintaining/patching the mailing list, unaware of DMARC, etc.)

Again, I think MLM header munging is here to stay, and list recipients needs to 
get used to it (I'd like p=quarantine pct=0 be the default behavior so that 
domains choosing to misdeploy DMARC aren't second class).  

I'd like to see a way to un-munge mail from trusted intermediaries, but that 
sounds impractical.  

I think ARC has promise but it has some challenges that I hope can be overcome; 
notably a mechanism for the receiver to indicate trust to the intermediary (so 
that it knows it doesn't need to munge).

At that point, I can start to figure out how to deal with the mailbox-level 
forwarded mail for faculty/alumni/emeriti...

Jesse

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

Re: [dmarc-ietf] non-mailing list use case for differing header domains

[Murray S. Kucherawy]

On Sun, Aug 2, 2020 at 5:44 PM Douglas E. Foster <
fost...@bayviewphysicians.com> wrote:

> Murray took server too literally.   I have expressed before that a system
> could do a sender authentication lookup on List-ID as easily as on From.
> In this respect, it is similar to Dave's proposal, without the added
> complexity of additional identifiers.   So think "Registerd List-ID plus
> DKIM signature (or SPF, but DKIM seems both sufficient and preferable.)
>

If we take "server" to mean a tuple made up of a List-ID value and a "d="
value from a validated DKIM signature, which I believe is what you're
saying here, the first occurrence of this necessarily has no internal value
(or history) attached to it.  That means the operator has to develop
meaning for it over time, which doesn't tell it how to handle the first N
such messages.  Err on the side of openness and you have a spam or attack
vector; err on the side of defense and you irritate your users by denying
them some list traffic until a reputation can develop.

And it's probably actually a three-tuple, with the third part being the
recipient.  Otherwise, I could register (or trigger the auto-registration
of) any two-tuple I want and thus intentionally let in my preferred list
streams, good or bad, which affects every other user.

Plus, you're trusting users to get this right.  For a manual registration
scheme, every time they get it wrong by entering the wrong data or failing
to even do it at all, you've got a failure mode to deal with, usually in
the form of user complaints which require other humans to resolve.  That
makes it relatively expensive.

And finally, lists change once in a while, maybe to a new signing domain,
maybe to a new name, maybe both.  Every time that happens, the process has
to start over.  Naturally lists won't want to do this because of the
sterling reputations they've developed, but the pain reappears whenever the
process needs to be repeated for whatever reason.

I'm not saying such a system can't or won't work.  I'm also not saying I
have a better idea.  I am saying there's multi-faceted pain in every
direction in this space, and this is no exception.  Whatever path we choose
to deploy here has to account for those choices and their side effects, and
the ways they might be gamed.

I am not sure what "Internet Scale" means to you.   Most of the major
> recipients have bulk mailer registration systems.   It does not guarantee
> whitelisting, but it tends to produce that effect.   I have had occasion to
> register with most of them.   So "does not scale" is not obvious to me.
>

"Internet Scale" means millions or billions of users, like GMail or Yahoo
or AOL or Microsoft have.  Since they have the bulk of the inboxes, a
solution needs to at least consider that size of use case, or explain why
those cases don't need to be considered.

I've never seen this manual registration process to which you refer.  Where
can I find it, for example, on GMail?

Even more to the point, check out this link:
>
> https://blog.postmaster.verizonmedia.com/post/616023179026202624/increasing-relevance-performance-through-vto
>
>
> Verizon appears to be offering a service (probably for extra cost) which
> is based on:
> (a) a well-defined mail stream from a known sender, and
> (b) a mailbox user identifying that mail stream as subscribed, and
> therefore desirable.
>
> It appears that the target senders are retailers who want to ensure that
> their sale announcements are read before the sale is over.   It is an
> "Internet scale" application of the type of registration I was suggesting:
>   Well-identified senders, coupled with end-user endorsement, receive
> preferred treatment.
>

Is there a technical description someplace of the mechanism behind what
they're doing?

As to the transparency question, it should be clear that there will be no
> simple solution to the ML problem.
>

Indeed.

[...] But the only way to establish an acceptable reputation is to either
> register with the receiver directly, or register with the sender in a way
> that the receiver will honor.
>

This needs to scale, from both ends:

1) If I as a new list operator want my list traffic to get accepted, how
could I possibly go about registering with all (or even most) mailbox
providers in a way they will trust?

2) If I as a mailbox provider want to give my users quality service and
also spam filtering, what way can I offer list operators to identify
themselves that can't be spoofed, and will only be exploited by good
actors?  Putting this burden on my users doesn't feel tenable.

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

Re: [dmarc-ietf] non-mailing list use case for differing header domains

[John Levine]

In article 

 you write:
>I feel like what is happening sometimes is that central university IT is 
>trying to drag their whole institutions into a
>more secure posture before anybody in a position to stop them fully 
>understands what's going on lest they be told to
>stop because it might make things a little inconvenient.

I was with you up until that sentence, since it trivializes the real
problems that overly strict DMARC policies cause.

Just yesterday I was sorting out a problem with people trying to
finish editing a revised IETF standard about real-time web
applications. Some of the authors' messages were disappearing,
apparently at random. I saw what the problem was, one of the authors
is at a big company whose IT department insists on p=reject (and has
blown off complaints from fairly senior people about the problems it
causes), the other uses an MIT alumni address that recently moved its
hosting to Microsoft without telling anyone that the new host enforces
DMARC policy while the old one didn't.

My guess is that MIT figured Microsoft will host this for free, that's
great, totally unaware that some of its users' mail would silently
break.

I told them as a workaround they needed to directly cc each other when
they send anything to the group list, but the whole thing is a
self-inflicted wound.

R's,
John

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

Re: [dmarc-ietf] non-mailing list use case for differing header domains

[Autumn Tyr-Salvia]

What I find very interesting about this email from Jesse, and Mike's response 
is that I hear these words coming from two very different experiences of 
deploying DMARC.

In my role doing onboarding at Agari, I have worked with many different 
organizations on their DMARC projects. I have worked with numerous corporate 
groups, as well as governmental organizations, nonprofits, and universities. 
Universities operate with a somewhat different set of expectations than other 
groups in ways that make DMARC additionally challenging.

Here are a few things I have learned implementing DMARC for multiple 
universities:

  *   Universities have a significantly higher degree of user and use case 
turnover than other organizations, by a lot. There are new students and staff 
every term, and many more of them will use their email address to send out 
email over various third party tools. In the corporate world, sure there are 
employees coming and going all the time, and new projects, but there is a much 
greater degree of stability in terms of systems sending out email.
  *   University IT has much less control over their users than corporate IT. 
In corporate IT, it is not unusual for IT leadership to make decisions on what 
applications will and will not be supported, and to have general support for 
this from the top. In higher education, IT teams seem to frequently be told 
that they must support whatever their users request, and have very little 
authority.
  *   Most universities serve a greater breadth of use cases than most other 
organizations. Consider an organization that is a fundraising nonprofit, 
scientific research group in multiple disciplines, hospital, mental health 
clinic, employer with HR tools, housing coordinator, childcare coordinator, 
gym, sports arena, transportation system, provider of continuing education to 
certified professionals, press agency, mailing list provider, forwarder, etc. 
all in one. There are a lot of niche tools that can send email in each of these 
different use cases, but universities are the only place I see so many of them 
all together.
  *   Universities are highly decentralized. It seems like every major school 
inside a university (school of public health, school of humanities, etc.) has 
its own policies and culture, and sometimes its own IT staff.
  *   Universities tend to have more legacy technology than other organizations 
(except government).

The reason I mention all this stuff is that I feel like some of what is being 
suggested here misses this reality.

Mike said, "You need buy-in from senior management for any email authentication 
efforts. When you add up the costs of customer support contacts for dealing 
with fraudulent email claiming to be from your organization, reputation damage, 
etc., management becomes more willing to buy into a comprehensive strategy." - 
in the higher education world, I don't see it working like this. IT staff can 
get enough buy-in to decide to work on DMARC as a project, but the costs of 
support contacts are likely spread out over multiple groups in a way that is 
very hard to quantify at a higher level, and even if they were to consider 
that, they would still be more likely to say that a comprehensive strategy is 
good and all, but it still matters more to them that good old Professor 1984 
can still use his favorite application even though it doesn't conform to modern 
security standards.

I feel like what is happening sometimes is that central university IT is trying 
to drag their whole institutions into a more secure posture before anybody in a 
position to stop them fully understands what's going on lest they be told to 
stop because it might make things a little inconvenient. Many universities do 
not attempt DMARC at all, so I think any work we can do to make it easier on 
them would encourage greater adoption.


Thanks,

Autumn Tyr-Salvia
atyrsal...@agari.com
Agari Principal Customer Success Engineer




From: dmarc  on behalf of Dotzero 
Sent: Wednesday, August 5, 2020 12:52 PM
To: Jesse Thompson 
Cc: IETF DMARC WG 
Subject: Re: [dmarc-ietf] non-mailing list use case for differing header domains



On Wed, Aug 5, 2020 at 12:39 PM Jesse Thompson 
mailto:40wisc@dmarc.ietf.org>> 
wrote:
On 8/4/20 11:52 AM, Alessandro Vesely wrote:
> On 2020-08-04 6:10 p.m., Dotzero wrote:
>> On Tue, Aug 4, 2020 at 11:39 AM Jim Fenton 
>> mailto:fen...@bluepopcorn.net>> wrote:
>>> On 8/2/20 5:43 PM, Douglas E. Foster wrote:
>>>> As to the transparency question, it should be clear that there will be
>>>> no simple solution to the ML problem.
>>>
>>> Actually, there is: If your domain has users that use mailing lists,
>>> don't publish 'reject' or 'quarantine' policies. Generally this means to
>>> just use those policies for domains used for transactional email.
>>>
>>&g

Re: [dmarc-ietf] non-mailing list use case for differing header domains

[Alessandro Vesely]

On 2020-08-05 9:52 p.m., Dotzero wrote:
> Required authentication for .gov domains moved forward in fits and
> starts up to the point of the DHS mandate. DHS approached the use
> of DMARC and authentication as a blunt one size fits all
> instrument.

That makes sense!  If you look at email from a user POV, how can you
justify the fact that transactional mail is protected while ordinary
people's identities can be seized scot-free?

I think DHS interprets a general feeling.

> 
> The reality is that the devil is always in the details.


Right, and we're the fairy godmother who gotta work them out.  With
From: rewriting, Author: Sender:, To:, and DKIM transforms we're well
into it, aren't we?


Best
Ale
-- 















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

Re: [dmarc-ietf] non-mailing list use case for differing header domains

[Dotzero]

On Wed, Aug 5, 2020 at 12:39 PM Jesse Thompson  wrote:

> On 8/4/20 11:52 AM, Alessandro Vesely wrote:
> > On 2020-08-04 6:10 p.m., Dotzero wrote:
> >> On Tue, Aug 4, 2020 at 11:39 AM Jim Fenton 
> wrote:
> >>> On 8/2/20 5:43 PM, Douglas E. Foster wrote:
>  As to the transparency question, it should be clear that there will be
>  no simple solution to the ML problem.
> >>>
> >>> Actually, there is: If your domain has users that use mailing lists,
> >>> don't publish 'reject' or 'quarantine' policies. Generally this means
> to
> >>> just use those policies for domains used for transactional email.
> >>>
> >>> Unfortunately we seem to be focused on very complex technical solutions
> >>> to a misdeployment problem.
>
> I've never heard this misdeployment viewpoint in the context of M3AAWG, so
> that might be a good audience to validate the viewpoint that users' domains
> can't benefit from p=quarantine|reject.  Perhaps it should be included in a
> BCP?  Maybe it is, and I'm misremembering?  Granted, I've only been a
> member for a few years.  Maybe it was a common understanding years ago and
> no one talks about it anymore?
>

Not a knock on M3AAWG but many of the members are more interested in
deliverability than anti-abuse. The Sender side of M3AAWG is dominated by
ESPs rather than Brand Senders. I say this as the Founder and Chair of
Brand SIG for 10 years until I left my employer that was a member of M3AAWG.

>
> For example, when I was invited by the technical committee to present our
> strategy and challenges deploying DMARC for our institution, no one told me
> we were misdeploying.  The session was pretty well attended, and I don't
> think I put everyone to sleep.  Now I feel like my speech was
> counterproductive because I may have encouraged others to misdeploy DMARC
> too.
>

You were presenting what you did. It may or may not have been
counterproductive.

>
>
> >> There is another solution. Move users to a separate domain from the
> domain
>
> Long ago we put users on our org domain as a way to unify users (in a very
> decentralized institution) under a single domain identity, and that
> branding decision is not going to be undone, politically.  Any project to
> move users from one domain identity to another is a huge lift; it takes a
> lot of time, effort, and never actually completes due to stragglers with
> very legitimate reasons to not give up sending from their old address.
>

I implemented for an Enterprise with large ecommerce/social sites and 20k
seats. The only people that were allowed to keep accounts on the primary
domains were people who directly supported the websites and they were not
allowed to use those accounts for anything other than supporting the
websites. They had accounts at the other domain just as all the other users.

>
> I think that end-users would rather see their list mail be rewritten than
> be told to change their identity.  I know that some people on this list
> think that the domain in the from header isn't commonly visible anymore,
> but the domain is extremely important to users' sense of identity.
>

Their identity at that organization is subject to the determinations of the
organization. It is amazing how quickly after a one time transition that
users get used to  their new "identity".

>
>
> >> your transactional mails are sent from. You can also put users on a
> >> separate subdomain.
>
> To the idea of clean separation:  We only encourage (without DMARC there
> is no way to enforce) subdomains for transactional email despite "brand
> minded" people insisting on using the org domain (or just using it without
> asking).  Despite everyone having an address in the org domain, we still
> have many users using legacy subdomains, and some of those subdomains are
> mixed-use.
>

You need buy-in from senior management for any email authentication
efforts. When you add up the costs of customer support contacts for dealing
with fraudulent email claiming to be from your organization, reputation
damage, etc., management becomes more willing to buy into a comprehensive
strategy.

>
> DMARC is great for getting visibility on this "separation" problem.  It's
> not until we moved past p=none that we could get any sticks behind our
> carrots.
>
> What I'm saying is that mixed-use domains are common and they proliferated
> due to the lack of domain alignment enforcement prior to DMARC.  Even when
> there is intention by IT to separate the use cases, they need DMARC to get
> both the visibility and the manageability/enforcement.
>

If it is only IT pushing this, you are probably doomed to failure.


>
> I've observed other universities using their single org domain for
> everything, and they don't find out they have a problem until they try to
> implement DMARC.  It's easier for them to move the transactional email to
> subdomains than to move users.  That is, unless they just give up on the
> idea of DMARC altogether.
>

Organizations make choices based on perceived 

Re: [dmarc-ietf] non-mailing list use case for differing header domains

[Jesse Thompson]

On 8/4/20 11:52 AM, Alessandro Vesely wrote:
> On 2020-08-04 6:10 p.m., Dotzero wrote:
>> On Tue, Aug 4, 2020 at 11:39 AM Jim Fenton  wrote:
>>> On 8/2/20 5:43 PM, Douglas E. Foster wrote:
 As to the transparency question, it should be clear that there will be
 no simple solution to the ML problem.
>>>
>>> Actually, there is: If your domain has users that use mailing lists,
>>> don't publish 'reject' or 'quarantine' policies. Generally this means to
>>> just use those policies for domains used for transactional email.
>>>
>>> Unfortunately we seem to be focused on very complex technical solutions
>>> to a misdeployment problem.

I've never heard this misdeployment viewpoint in the context of M3AAWG, so that 
might be a good audience to validate the viewpoint that users' domains can't 
benefit from p=quarantine|reject.  Perhaps it should be included in a BCP?  
Maybe it is, and I'm misremembering?  Granted, I've only been a member for a 
few years.  Maybe it was a common understanding years ago and no one talks 
about it anymore?

For example, when I was invited by the technical committee to present our 
strategy and challenges deploying DMARC for our institution, no one told me we 
were misdeploying.  The session was pretty well attended, and I don't think I 
put everyone to sleep.  Now I feel like my speech was counterproductive because 
I may have encouraged others to misdeploy DMARC too.


>> There is another solution. Move users to a separate domain from the domain

Long ago we put users on our org domain as a way to unify users (in a very 
decentralized institution) under a single domain identity, and that branding 
decision is not going to be undone, politically.  Any project to move users 
from one domain identity to another is a huge lift; it takes a lot of time, 
effort, and never actually completes due to stragglers with very legitimate 
reasons to not give up sending from their old address.  

I think that end-users would rather see their list mail be rewritten than be 
told to change their identity.  I know that some people on this list think that 
the domain in the from header isn't commonly visible anymore, but the domain is 
extremely important to users' sense of identity.  


>> your transactional mails are sent from. You can also put users on a
>> separate subdomain.

To the idea of clean separation:  We only encourage (without DMARC there is no 
way to enforce) subdomains for transactional email despite "brand minded" 
people insisting on using the org domain (or just using it without asking).  
Despite everyone having an address in the org domain, we still have many users 
using legacy subdomains, and some of those subdomains are mixed-use.  

DMARC is great for getting visibility on this "separation" problem.  It's not 
until we moved past p=none that we could get any sticks behind our carrots.  

What I'm saying is that mixed-use domains are common and they proliferated due 
to the lack of domain alignment enforcement prior to DMARC.  Even when there is 
intention by IT to separate the use cases, they need DMARC to get both the 
visibility and the manageability/enforcement.

I've observed other universities using their single org domain for everything, 
and they don't find out they have a problem until they try to implement DMARC.  
It's easier for them to move the transactional email to subdomains than to move 
users.  That is, unless they just give up on the idea of DMARC altogether.

This might be a stretch, but I think the "DMARC is different for user vs 
transactional domains argument" dovetails with the need for sp to walk the 
domain tree.  If the assertion is that the domain with users is fundamentally 
different than domains used for transactional email, and most institutions use 
their org domain for their users, and subdomains are a mixed bag of varying use 
cases, then the org domain's DMARC policy isn't the best candidate for 
inheritance.  


> Yet another solution would be to not use DMARC.  The status quo ante.
> 
> While p=none is a technically valid position, there seems to be a
> demand of a mail infrastructure where spoofing is not allowed.

Not only a demand, but a requirement: https://cyber.dhs.gov/bod/18-01/

I don't think DHS got the memo about misdeploying DMARC, either.  I know that 
around 2018, the person maintaining the MLM for our astrophysics center had to 
scramble to implement header munging because of all of the .gov's publishing 
p=reject

Jesse

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

Re: [dmarc-ietf] non-mailing list use case for differing header domains

[Alessandro Vesely]

On 2020-08-04 6:10 p.m., Dotzero wrote:
> On Tue, Aug 4, 2020 at 11:39 AM Jim Fenton  wrote:
>> On 8/2/20 5:43 PM, Douglas E. Foster wrote:
>>> As to the transparency question, it should be clear that there will be
>>> no simple solution to the ML problem.
>>
>> Actually, there is: If your domain has users that use mailing lists,
>> don't publish 'reject' or 'quarantine' policies. Generally this means to
>> just use those policies for domains used for transactional email.
>>
>> Unfortunately we seem to be focused on very complex technical solutions
>> to a misdeployment problem.
>>
>>
> There is another solution. Move users to a separate domain from the domain
> your transactional mails are sent from. You can also put users on a
> separate subdomain.


Yet another solution would be to not use DMARC.  The status quo ante.

While p=none is a technically valid position, there seems to be a
demand of a mail infrastructure where spoofing is not allowed.


Best
Ale
-- 























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

Re: [dmarc-ietf] non-mailing list use case for differing header domains

[Dotzero]

On Tue, Aug 4, 2020 at 11:39 AM Jim Fenton  wrote:

> On 8/2/20 5:43 PM, Douglas E. Foster wrote:
> > As to the transparency question, it should be clear that there will be
> > no simple solution to the ML problem.
>
> Actually, there is: If your domain has users that use mailing lists,
> don't publish 'reject' or 'quarantine' policies. Generally this means to
> just use those policies for domains used for transactional email.
>
> Unfortunately we seem to be focused on very complex technical solutions
> to a misdeployment problem.
>
> -Jim
>
>
There is another solution. Move users to a separate domain from the domain
your transactional mails are sent from. You can also put users on a
separate subdomain.

There are many ways for this to be addressed without coming up with complex
standards solutions.

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

Re: [dmarc-ietf] non-mailing list use case for differing header domains

[Jim Fenton]

On 8/2/20 5:43 PM, Douglas E. Foster wrote:
> As to the transparency question, it should be clear that there will be
> no simple solution to the ML problem. 

Actually, there is: If your domain has users that use mailing lists,
don't publish 'reject' or 'quarantine' policies. Generally this means to
just use those policies for domains used for transactional email.

Unfortunately we seem to be focused on very complex technical solutions
to a misdeployment problem.

-Jim

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

Re: [dmarc-ietf] non-mailing list use case for differing header domains

[Jim Fenton]

On 8/2/20 2:24 PM, John R Levine wrote:
>>> If they would provide a way to register a mailing list and the servers
>>> from which it comes, and allow DMARC exceptions for traffic from those
>>> registered lists, your situation would be much easier?
>
> If large mail providers were willing to whitelist known mailing lists
> we wouldn't need ARC.

And as has been pointed out (perhaps also by John), ARC still requires
an allowlist or some other way to determine who is allowed to make
authenticated changes to a message.

-Jim


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

Re: [dmarc-ietf] non-mailing list use case for differing header domains

[Kurt Andersen (b)]

This is a known issue with many calendaring frameworks. Besides the issue
of delegates who are sending on behalf of someone in another domain, most
calendaring systems send "forwarded" invitations by trying to resend in the
name of the event originator.

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

Re: [dmarc-ietf] non-mailing list use case for differing header domains

[Benny Pedersen]

John R Levine skrev den 2020-08-02 23:24:


If large mail providers were willing to whitelist known mailing lists
we wouldn't need ARC.


if no one breaked dkim then we did not need arc


See previous messages for why that isn't sufficient.


missing arc will not break spf dkim, but it preserves state of pass TO 
the maillists, but only if maillists run arc at the first stage of 
breaking dkim, i only know dovecot maillist that have solved it as it 
should be, i think others could do the same of not breaking dkim, or if 
need to, do a fully arc sealing


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

Re: [dmarc-ietf] non-mailing list use case for differing header domains

[Ken O'Driscoll]

On 03/08/2020 01:43, Douglas E. Foster wrote:
>
> I am not sure what "Internet Scale" means to you.   Most of the major
> recipients have bulk mailer registration systems.   It does not
> guarantee whitelisting, but it tends to produce that effect.   I have
> had occasion to register with most of them.   So "does not scale" is
> not obvious to me.

This is not correct. In the past some large providers did offer such
lists but these days most have moved away from that model for various
reasons. You'll still find someone offering such as service, and
pay-to-play is a thing too but none of this is a) widespread and b)
based on any type of standard - it's all proprietary. The same goes for
sender certification services such as ReturnPath.

"Internet Scale" means being able to scale to internet level of usage
and platform interoperability.  TCP/IP and DNS are good examples. Data
(e.g. lists of approved senders) maintained internally by individual
organisations can't scale to that level for the same reason that
organisations siloing their own DNS and routing information wouldn't
work. Interoperability.

Organisations publishing information (e.g. an SPF record) in their DNS
zone works because it's based on an existing internet scale
interoperable platform. While the "heavy lifting" of interpreting the
SPF record might be undertaken by a variety of different software and
system platforms, the mechanism is standardised based on the RFC. Again,
interoperability.

Ken.

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

Re: [dmarc-ietf] non-mailing list use case for differing header domains

[Douglas E. Foster]

Murray took server too literally.   I have expressed before that a system could 
do a sender authentication lookup on List-ID as easily as on From.   In this 
respect, it is similar to Dave's proposal, without the added complexity of 
additional identifiers.   So think "Registerd List-ID plus DKIM signature (or 
SPF, but DKIM seems both sufficient and preferable.)

I am not sure what "Internet Scale" means to you.   Most of the major 
recipients have bulk mailer registration systems.   It does not guarantee 
whitelisting, but it tends to produce that effect.   I have had occasion to 
register with most of them.   So "does not scale" is not obvious to me.

Even more to the point, check out this link:
https://blog.postmaster.verizonmedia.com/post/616023179026202624/increasing-relevance-performance-through-vto

Verizon appears to be offering a service (probably for extra cost) which is 
based on:
(a) a well-defined mail stream from a known sender, and
(b) a mailbox user identifying that mail stream as subscribed, and therefore 
desirable.

It appears that the target senders are retailers who want to ensure that their 
sale announcements are read before the sale is over.   It is an "Internet 
scale" application of the type of registration I was suggesting:   
Well-identified senders, coupled with end-user endorsement, receive preferred 
treatment.

As to the transparency question, it should be clear that there will be no 
simple solution to the ML problem.  As long as mailing lists appear identical 
to a malicious spoofer, their only protection is their own sterling reputation. 
  But the only way to establish an acceptable reputation is to either register 
with the receiver directly, or register with the sender in a way that the 
receiver will honor.Your proposal does nothing to distinguish mailing lists 
from malicious spoofers, so it does nothing to solve the problem.   Mailing 
lists either need to send using the ML domain as the From address, not modify 
the message, or establish a credible reputation.   There are no other 
possibilities on this side of FantasyLand.

DF


From: Dave Crocker 
Sent: 8/2/20 5:29 PM
To: IETF DMARC WG 
Subject: Re: [dmarc-ietf] non-mailing list use case for differing header domains
On 8/2/2020 2:22 PM, Murray S. Kucherawy wrote:
> Ignoring for the moment the problems of scale with any "register your
> lists" solution, I don't think users can reasonably be expected to
> keep such a registration current if, say, the servers were to move.
> Such a migration would no longer be transparent, as it is today.

+1

When someone proposes a scheme, it will help for them to list who the
relevant actors must be and what they must do and then deal with the
question of scaling.  That is, how will it be possible for this to work
at Internet scale?

d/

--
Dave Crocker
Brandenburg InternetWorking
bbiw.net

___
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] non-mailing list use case for differing header domains

[Dave Crocker]

On 8/2/2020 2:22 PM, Murray S. Kucherawy wrote:
Ignoring for the moment the problems of scale with any "register your 
lists" solution, I don't think users can reasonably be expected to 
keep such a registration current if, say, the servers were to move.  
Such a migration would no longer be transparent, as it is today.


+1

When someone proposes a scheme, it will help for them to list who the 
relevant actors must be and what they must do and then deal with the 
question of scaling.  That is, how will it be possible for this to work 
at Internet scale?


d/

--
Dave Crocker
Brandenburg InternetWorking
bbiw.net

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

Re: [dmarc-ietf] non-mailing list use case for differing header domains

[John R Levine]

If they would provide a way to register a mailing list and the servers
from which it comes, and allow DMARC exceptions for traffic from those
registered lists, your situation would be much easier?


If large mail providers were willing to whitelist known mailing lists we 
wouldn't need ARC.


See previous messages for why that isn't sufficient.

Regards,
John Levine, jo...@taugh.com, Taughannock Networks, Trumansburg NY
Please consider the environment before reading this e-mail. https://jl.ly

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

Re: [dmarc-ietf] non-mailing list use case for differing header domains

[Murray S. Kucherawy]

On Sun, Aug 2, 2020 at 11:55 AM Douglas E. Foster <
fost...@bayviewphysicians.com> wrote:

> If they would provide a way to register a mailing list and the servers
> from which it comes, and allow DMARC exceptions for traffic from those
> registered lists, your situation would be much easier?
>

Ignoring for the moment the problems of scale with any "register your
lists" solution, I don't think users can reasonably be expected to keep
such a registration current if, say, the servers were to move.  Such a
migration would no longer be transparent, as it is today.

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

Re: [dmarc-ietf] non-mailing list use case for differing header domains

[John R Levine]

Is it fair to say that AOL/Yahoo/Verizon is the core of the problem for you?


No, it is fair to say that misuse of DMARC is the problem.

Regards,
John Levine, jo...@taugh.com, Taughannock Networks, Trumansburg NY
Please consider the environment before reading this e-mail. https://jl.ly

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

Re: [dmarc-ietf] non-mailing list use case for differing header domains

[Douglas E. Foster]

Is it fair to say that AOL/Yahoo/Verizon is the core of the problem for you?

If they would provide a way to register a mailing list and the servers from 
which it comes, and allow DMARC exceptions for traffic from those registered 
lists, your situation would be much easier?

DF


From: "John Levine" 
Sent: 8/2/20 12:58 PM
To: dmarc@ietf.org
Cc: fost...@bayviewphysicians.com
Subject: Re: [dmarc-ietf] non-mailing list use case for differing header domains
In article  you write:
>I wonder if this is typical - are mailing list subscribers more likely to be 
>on DMARC-enforcing domains than the general population?
>
>Do the mailing list operators have data about what percentage of their 
>subscribers (or percentage of unique domains) have DMARC policy enforcement in 
>place?

In my experience it completely depends on the list. I have a list of
folk dancers with a lot of old AOL and Yahoo addresses with DMARC
policies, and I have other lists where it's mostly gmail and
Hotmail/Outlook, without.

R's,
John


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

Re: [dmarc-ietf] non-mailing list use case for differing header domains

[John Levine]

In article  you write:
>I wonder if this is typical  - are mailing list subscribers more likely to be 
>on DMARC-enforcing domains than the general population?
>
>Do the mailing list operators have data about what percentage of their 
>subscribers (or percentage of unique domains) have DMARC policy enforcement in 
>place?

In my experience it completely depends on the list. I have a list of
folk dancers with a lot of old AOL and Yahoo addresses with DMARC
policies, and I have other lists where it's mostly gmail and
Hotmail/Outlook, without.

R's,
John




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

Re: [dmarc-ietf] non-mailing list use case for differing header domains

[Douglas E. Foster]

I have reviewed recent posts to this mailing list:   Submissions have come from 
39 different people on 34 unique domains.   Of these, 11 have munged headers, 
indicating that they use an enforceable DMARC policy.   This is a much higher 
percentage than your general survey.

I wonder if this is typical  - are mailing list subscribers more likely to be 
on DMARC-enforcing domains than the general population?

Do the mailing list operators have data about what percentage of their 
subscribers (or percentage of unique domains) have DMARC policy enforcement in 
place?

DF


From: Neil Anuskiewicz 
Sent: 8/1/20 9:27 PM
To: Luis E. Muñoz 
Cc: dmarc@ietf.org
Subject: Re: [dmarc-ietf] non-mailing list use case for differing header domains
I looked at ~3.5 million domain names and here's some of what I found. This 
data might be useful to the discussion. As for me, I'm lurking and learning.

Anyway, I looked at ~3.5 million domain names and here's some of what I found:

FTSE DMARC Adoption
 DMARC Policy10/18/2019
 No record   56%
 none34%
 quarantine  1%
 reject  9%

F500 DMARC Adoption

 DMARC Policy10/18/2019
 no record   49%
 none37%
 quarantine  4%
 reject  9%

ASX DMARC Adoption

 DMARC Policy10/18/2019
 no record   59%
 none33%
 quarantine  1%
 reject  7%

On Sat, Aug 1, 2020 at 12:57 PM Neil Anuskiewicz  wrote:

I looked at ~3.5 million domain names and here's some of what I found.. This 
wasn't a random sample but perhaps this data will be useful in this discussion:

FTSE DMARC Adoption
 Snapshot (10/18)

 No record   56%
 none34%
 quarantine  1%
 reject  9%

F500 DMARC Adoption
 Snapshot (10/18)

 no record   49%
 none37%
 quarantine  4%
 reject  9%

ASX DMARC Adoption
 Snapshot (10/18)

 no record   59%
 none33%
 quarantine  1%
 reject  7%

Thanks.

Neil
On Thu, Jul 30, 2020 at 6:02 PM Luis E. Muñoz 
 wrote:

On 30 Jul 2020, at 15:52, Jim Fenton wrote:

There's an underlying assumption here that I don't agree with: that
DMARC adoption equates to the publication of a p=reject DMARC policy,
and that everyone (or at least all Fortune 500 companies) should be
doing that. p=reject should only be used when the usage patterns of the
domain support that policy. I'm more inclined to say that 85% of Fortune
500 companies are savvy enough not to publish a policy that doesn't fit
their usage patterns.

I am currently observing ~215.5 million domain names. Out of those, ~64
million have a seemingly valid SPF record and ~113 million with at least one MX 
record.

This is a current breakdown of the (valid) DMARC records I am observing over 
the general domain population above. This amounts to an adoption rate of ~1.7%.
pcount
 none2715614
 quarantine  238584
 reject  726045

It is interesting that roughly half of those are not taking advantage of the 
reporting. Here are the counts for those with neither rua= nor ruf= in the 
DMARC records:
pcount
 none1092990
 quarantine  107767
 reject  307614

I do not have a definitive list of Fortune 500 domain names, but I compile a 
rolling list of domain names with most traffic using multiple sources, which 
currently holds ~1.8 million unique domain names.

The breakdown of DMARC records from that high-traffic population is shown 
below, and it amounts to about 6.3%.
pcount
 none79367
 quarantine  18094
 reject  15875

For completeness, here is the same report, counting only those that have 
neither rua= nor ruf= in the DMARC record. The ratio of silent p=quarantine and 
p=reject seems around half as in the case of the general population.
pcount
 none32561
 quarantine  4534
 reject  2760

It would seem that those high-traffic domains are ~5x more likely to adopt 
DMARC. To me, these numbers speaks of thoughtful and deliberate deployment that 
outpaces the general domain name registrations.

That said, I cannot claim whether the list of high-traffic domains is actually 
a good proxy for the domain portfolio of the Fortune 500 companies.

Best regards

-lem

___
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] non-mailing list use case for differing header domains

[Neil Anuskiewicz]

I looked at ~3.5 million domain names and here's some of what I found. This
data might be useful to the discussion. As for me, I'm lurking and learning..

Anyway, I looked at ~3.5 million domain names and here's some of what I
found:
FTSE DMARC Adoption
DMARC Policy 10/18/2019
No record 56%
none 34%
quarantine 1%
reject 9%

F500 DMARC Adoption
DMARC Policy 10/18/2019
no record 49%
none 37%
quarantine 4%
reject 9%
ASX DMARC Adoption
DMARC Policy 10/18/2019
no record 59%
none 33%
quarantine 1%
reject 7%





On Sat, Aug 1, 2020 at 12:57 PM Neil Anuskiewicz 
wrote:

> I looked at ~3.5 million domain names and here's some of what I found.
> This wasn't a random sample but perhaps this data will be useful in this
> discussion:
>
> FTSE DMARC Adoption
>
> Snapshot (10/18)
> No record 56%
> none 34%
> quarantine 1%
> reject 9%
> F500 DMARC Adoption
>
> Snapshot (10/18)
> no record 49%
> none 37%
> quarantine 4%
> reject 9%
>
> ASX DMARC Adoption
>
> Snapshot (10/18)
> no record 59%
> none 33%
> quarantine 1%
> reject 7%
>
> Thanks.
>
> Neil
> On Thu, Jul 30, 2020 at 6:02 PM Luis E. Muñoz  40lem.cl...@dmarc.ietf.org> wrote:
>
>> On 30 Jul 2020, at 15:52, Jim Fenton wrote:
>>
>> There's an underlying assumption here that I don't agree with: that
>> DMARC adoption equates to the publication of a p=reject DMARC policy,
>> and that everyone (or at least all Fortune 500 companies) should be
>> doing that. p=reject should only be used when the usage patterns of the
>> domain support that policy. I'm more inclined to say that 85% of Fortune
>> 500 companies are savvy enough not to publish a policy that doesn't fit
>> their usage patterns.
>>
>> I am currently observing ~215.5 million domain names. Out of those, ~64
>> million have a seemingly *valid* SPF record and ~113 million with at
>> least one MX record.
>>
>> This is a current breakdown of the (valid) DMARC records I am observing
>> over the general domain population above. This amounts to an adoption rate
>> of ~1.7%.
>> p count
>> none 2715614
>> quarantine 238584
>> reject 726045
>>
>> It is interesting that roughly half of those are not taking advantage of
>> the reporting. Here are the counts for those with neither rua= nor ruf=
>> in the DMARC records:
>> p count
>> none 1092990
>> quarantine 107767
>> reject 307614
>>
>> I do not have a definitive list of Fortune 500 domain names, but I
>> compile a rolling list of domain names with most traffic using multiple
>> sources, which currently holds ~1.8 million unique domain names.
>>
>> The breakdown of DMARC records from that high-traffic population is shown
>> below, and it amounts to about 6.3%.
>> p count
>> none 79367
>> quarantine 18094
>> reject 15875
>>
>> For completeness, here is the same report, counting only those that have
>> neither rua= nor ruf= in the DMARC record. The ratio of *silent*
>> p=quarantine and p=reject seems around half as in the case of the
>> general population.
>> p count
>> none 32561
>> quarantine 4534
>> reject 2760
>>
>> It would seem that those high-traffic domains are ~5x more likely to
>> adopt DMARC. To me, these numbers speaks of thoughtful and deliberate
>> deployment that outpaces the general domain name registrations.
>>
>> That said, I cannot claim whether the list of high-traffic domains is
>> actually a good proxy for the domain portfolio of the Fortune 500 companies.
>>
>> Best regards
>>
>> -lem
>> ___
>> 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] non-mailing list use case for differing header domains

[John R Levine]

On Fri, 31 Jul 2020, Jesse Thompson wrote:

I think they want their IT staff to deploy an email system and policies that 
work the way they would expect.  They want their organization to be seen as 
secure, so they don't want to be on the Buzzfeed list of Fortune 500 companies 
that have neglected to secure their domains with DMARC.


Well, that's the problem, isn't it?  If your expectations for e-mail are 
shaped by experience with paper mail and you don't realize how different 
an organization's internal highly controlled mail system is from e-mail on 
the outside, you're inevitably going to be surprised, sometimes 
unpleasantly.


I would like for us to avoid the Yes Minister Tautology: We must do 
something, this is something, therefore we must do this.


Regards,
John Levine, jo...@taugh.com, Taughannock Networks, Trumansburg NY
Please consider the environment before reading this e-mail. https://jl.ly

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

Re: [dmarc-ietf] non-mailing list use case for differing header domains

[John Levine]

In article  you write:
>I think you're right, and isn't the market indicating that there is demand for 
>DMARC designed for other usage patterns?  e.g.
>Would the CEO of any of those fortune 500 companies like the idea of their 
>personal address being spoofed?

I dunno. Would they like the idea of mail their assistants send out
for them being silently discarded because it's falsely tagged as being
"spoofed"?

R's,
John

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

Re: [dmarc-ietf] non-mailing list use case for differing header domains

[Alessandro Vesely]

On Wed 29/Jul/2020 19:34:48 +0200 Hector Santos wrote:

On 7/28/2020 1:19 PM, Doug Foster wrote:

Hector, I do not understand this comment:

"The DKIM Policy Model since ADSP lacked the ability to authorize 3rd party 
domains. DMARC did not address the problem and reason ADSP was abandoned. 
Hence the on-going dilemma."




[...]

We have DKIM Policy extension proposals like ATPS (RFC6541) that offers a 
deterministic method to associate the author domain with 3rd party signer 
domains.   This authorization is defined by the Originating, Author Domain.


Look at my DMARC record for my isdg.net domain:

v=DMARC1; p=reject; atps=y; rua=mailto:dmarc-...@isdg.net; 
ruf=mailto:dmarc-...@isdg.net;


The atps=y tells an ATPS compliant receiver that if it sees a 3rd party domain 
signature:


   Author Domain IS NOT EQUAL TO Signer Domain

Then it can do a ATPS look:

    base32(sha1(SIGNER-DOMAIN))._atps.isdg.net

So if I wanted to authorized bayviewphysicians.com to be able to sign for me, I 
would go to the wizard https://secure.winserver.com/public/wcdmarc,  enter your 
domain in the list of authorized signers, click Zone Record and I get a record 
I can add to my isdg.net zone:


e25dhs2vmyjf2tc2df4efpeu7js7hbik._atps  TXT ("v=atps01; 
d=bayviewphysicians.com;")

So anyone out there can see that I authorized bayviewphysicians.com to sign for 
isdg.net



Isn't that overly complicated?  Why SHA1?  An alternative method to authorize 
3rd parties is RHSWLs, see my previous post[*].  By comparison with the above 
quote, assume we have:


From: some...@example.com
Sender: a...@example.net

The DMARC record at example.com:

v=DMARC1; p=reject; snd=lst.rhswl.example; rua=mailto:r...@example.com;

The snd=lst.rhswl.example tells a compliant receiver that if it sees a 3rd 
party authentication (either SPF or DKIM) of the Sender domain:, where:


From: domain IS NOT EQUAL TO Sender: domain

Then it can do a right-hand side whitelist lookup:

example.net.lst.rhswl.example

If the record exists, then example.net is authorized to send on behalf of 
example.com.



Features:

* Absence of cryptographic stuff (sha1) makes it simpler.

* A multi-domain bank (Autumn's example) can easily build its own RHSWL 
containing all and only their domains, e.g.:


  firstbrand.com.lst.mainbrand.com  IN A 127.0.0.2
  secondbrand.com.lst.mainbrand.com IN A 127.0.0.2

* Large free-email domains can build their own RHSWL so as to avoid the MLM 
problem.


* Lazy mail domains can easily point to a public RHSWL which lists almost all 
the legitimate Internet.


* Strictly transactional domains can still keep snd=none (the default).

* Experimenting domains can have p=none; snd=lst.in-progress.example; while 
they monitor aggregate reports to see how their list is doing.



Best
Ale
--

[*] https://mailarchive.ietf.org/arch/msg/dmarc/jQlUhE-ijiWeb1CybKy6367eVn8


























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

Re: [dmarc-ietf] non-mailing list use case for differing header domains

[Luis E. Muñoz]

On 30 Jul 2020, at 15:52, Jim Fenton wrote:


There's an underlying assumption here that I don't agree with: that
DMARC adoption equates to the publication of a p=reject DMARC policy,
and that everyone (or at least all Fortune 500 companies) should be
doing that. p=reject should only be used when the usage patterns of 
the
domain support that policy. I'm more inclined to say that 85% of 
Fortune
500 companies are savvy enough not to publish a policy that doesn't 
fit

their usage patterns.


I am currently observing ~215.5 million domain names. Out of those, ~64
 million have a seemingly _valid_ SPF record and ~113 million with at 
least one MX record.


This is a current breakdown of the (valid) DMARC records I am observing 
over the general domain population above. This amounts to an adoption 
rate of ~1.7%.


|p   |  count  |
| :- | --: |
| none   | 2715614 |
| quarantine |  238584 |
| reject |  726045 |

It is interesting that roughly half of those are not taking advantage of 
the reporting. Here are the counts for those with neither `rua=` nor 
`ruf=` in the DMARC records:


|p   |  count  |
| :- | --: |
| none   | 1092990 |
| quarantine |  107767 |
| reject |  307614 |

I do not have a definitive list of Fortune 500 domain names, but I 
compile a rolling list of domain names with most traffic using multiple 
sources, which currently holds ~1.8 million unique domain names.


The breakdown of DMARC records from that high-traffic population is 
shown below, and it amounts to about 6.3%.


|p   | count |
| :- | : |
| none   | 79367 |
| quarantine | 18094 |
| reject | 15875 |

For completeness, here is the same report, counting only those that have 
neither `rua=` nor `ruf=` in the DMARC record. The ratio of _silent_ 
`p=quarantine` and `p=reject` seems around half as in the case of the 
general population.


|p   | count |
| :- | : |
| none   | 32561 |
| quarantine |  4534 |
| reject |  2760 |

It would seem that those high-traffic domains are ~5x more likely to 
adopt DMARC. To me, these numbers speaks of thoughtful and deliberate 
deployment that outpaces the general domain name registrations.


That said, I cannot claim whether the list of high-traffic domains is 
actually a good proxy for the domain portfolio of the Fortune 500 
companies.


Best regards

-lem

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

Re: [dmarc-ietf] non-mailing list use case for differing header domains

[Jim Fenton]

On 7/28/20 2:07 AM, Laura Atkins wrote:
> The underlying belief with DMARC is that mail is simple, that
> companies are monoliths with only a few brands/domains, that it is
> possible to know exactly where every message will come from. These
> assumptions are not and have never been true. Inevitably, however,
> when these types of issues are pointed out, they’re dismissed with
> “solutions” that aren’t actually achievable or maintainable. DMARC
> proponents have repeatedly failed to pay attention to folks pointing
> out the actual operational challenges and thus have never addressed
> the issues in any way. This is, fundamentally, why only 15% of fortune
> 500 companies have adopted p=reject and why adoption rates are only
> increased by 5% last year. 
>
> The indirect mail stream issue is real. But it is not the only barrier
> to getting to p=reject. The sooner folks start listening to the people
> who are presenting real issues where DMARC alignment can’t be achieved
> the sooner they’ll be able to address them. The problem with low DMARC
> adoption is that it does not adequately address how companies are
> using mail in ways that break the DMARC model. Almost a decade on, and
> proponents are still suggesting that email usage should change to
> comply with their model of how email works. This has not happened.
> Maybe proponents need to think harder about why. 


There's an underlying assumption here that I don't agree with: that
DMARC adoption equates to the publication of a p=reject DMARC policy,
and that everyone (or at least all Fortune 500 companies) should be
doing that. p=reject should only be used when the usage patterns of the
domain support that policy. I'm more inclined to say that 85% of Fortune
500 companies are savvy enough not to publish a policy that doesn't fit
their usage patterns.

As RFC 7489 says, "DMARC is designed to prevent bad actors from sending
mail that claims to come from legitimate senders, particularly senders
of transactional email (official mail that is about business
transactions)." If the statistic were instead, "only 15% of domains used
exclusively for transactional email publish p=reject," I'd agree that's
a statistic that should be improved.

-Jim


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

Re: [dmarc-ietf] non-mailing list use case for differing header domains

[Jesse Thompson]

On 7/30/20 2:47 PM, superu...@gmail.com wrote:
> Email domains that have more than a few users don't want to authorize 
> every potential 3rd party (converges quickly to all of them, for 
> large/complex organizations) to sign as every user/address in the domain.  
> Even if SPF didn't have the 10 DNS lookup limitation, I would not choose put 
> every 3rd party into our domains' SPF records.  I'd essentially be 
> authorizing most of the [legitimate] internet to use the domains.
> 
> 
> Yes, it has this scaling problem.  Had it been shown to be effective at 
> dealing with the indirect mail flows issues that DMARC forced to be 
> front-and-center a few years later, I imagine we could've revised ATPS to be 
> more scalable.

I almost suggested that an address-level authorization mechanism would be 
useful, but that seems un-scalable for manageability reasons.

Jesse

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

Re: [dmarc-ietf] non-mailing list use case for differing header domains

[Jesse Thompson]

On 7/30/20 2:47 PM, superu...@gmail.com wrote:
> Translated into IETF-ese: "I have not read your document but I do have an 
> opinion about it..."   ;-)

Yeah, Dave sent me that feedback too.  I was just trying to make it clear that 
I only have $0.02 to give, rather than trying to sound like I'm an expert on 
ATSP.  I'll avoid the cliche next time.

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

Re: [dmarc-ietf] non-mailing list use case for differing header domains

[Murray S. Kucherawy]

On Thu, Jul 30, 2020 at 10:26 AM Jesse Thompson  wrote:

> I admittedly know nothing about ATPS, but I think its fundamental problem
> is that it authorizes 3rd parties at the domain level and that makes it not
> much better than SPF, just different.
>

Translated into IETF-ese: "I have not read your document but I do have an
opinion about it..."   ;-)

Seriously though, yes, that's correct.  Note that its status is
Experimental; the goal was to see if this was a useful thing to implement
and upon which to iterate if the experiment yielded positive results.  But
I think there were only ever about two implementations.

Email domains that have more than a few users don't want to authorize every
> potential 3rd party (converges quickly to all of them, for large/complex
> organizations) to sign as every user/address in the domain.  Even if SPF
> didn't have the 10 DNS lookup limitation, I would not choose put every 3rd
> party into our domains' SPF records.  I'd essentially be authorizing most
> of the [legitimate] internet to use the domains.
>

Yes, it has this scaling problem.  Had it been shown to be effective at
dealing with the indirect mail flows issues that DMARC forced to be
front-and-center a few years later, I imagine we could've revised ATPS to
be more scalable.

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

Re: [dmarc-ietf] non-mailing list use case for differing header domains

[Jesse Thompson]

On 7/29/20 12:34 PM, Hector Santos wrote:
> On 7/28/2020 1:19 PM, Doug Foster wrote:
>> Hector, I do not understand this comment:
>>
>> "The DKIM Policy Model since ADSP lacked the ability to authorize 3rd party 
>> domains. DMARC did not address the problem and reason ADSP was abandoned. 
>> Hence the on-going dilemma."
>>
> 
> SSP, ADSP and DMARC are technical specs for a DKIM POLICY Model.
> 
> The problem we have with DMARC was the same with SSP which was replaced by 
> ADSP which attempted to ignore the problem. Generally, as it often done with 
> ambiguous issues in the IETF, we ignore it, we make it out of scope, we keep 
> it open ended, etc.  It just wasn't resolved and ADSP was abandoned but 
> returned as DMARC but it also kept the same 3rd party ignorance as ADSP did.  
>  If this issue is not resolved for DMARC, I see an interesting situation 
> during DMARCBis Last Call explaining how we abandoned ADSP for having problem 
> XYZ and then reintroduced "SUPER ADSP" as DMARC but it still has the problem 
> XYZ.
> 
>> Domains that participate with a mailing list have the option of including 
>> the ML servers in their SPF record, or delegating them a DKIM scope and key. 
>>    But to obtain that authorization from the sending domain, someone would 
>> have to ask for it, and might not receive the desired answer.
>>
>> The goal of this discussion is to find a way to coerce trust.   We do not 
>> lack ways to grant trust on request.
> 
> This issue is not about the known, but the unknown. We don't have an issue 
> with proactive authorization and whitelisting methods.
> 
> I've been in this DKIM project for 15+ years, and to me, the goal has also 
> been to find a reasonable, scalable deterministic protocol that will handle 
> unsolicited, unknown 3rd party domain signers. Not necessarily unknown in a 
> bad sense, unknown that you don't know anything about them. So you ask the 
> author, "Hey, is this 3rd party signer ok?"
> 
> SPF allows 3rd party IP declarations.  DKIM POLICY model does not offer this 
> capability.
> 
> We have DKIM Policy extension proposals like ATPS (RFC6541) that offers a 
> deterministic method to associate the author domain with 3rd party signer 
> domains.   This authorization is defined by the Originating, Author Domain.
> 
> Look at my DMARC record for my isdg.net domain:
> 
> v=DMARC1; p=reject; atps=y; rua=mailto:dmarc-...@isdg.net; 
> ruf=mailto:dmarc-...@isdg.net;
> 
> The atps=y tells an ATPS compliant receiver that if it sees a 3rd party 
> domain signature:
> 
>   Author Domain IS NOT EQUAL TO Signer Domain
> 
> Then it can do a ATPS look:
> 
>    base32(sha1(SIGNER-DOMAIN))._atps.isdg.net
> 
> So if I wanted to authorized bayviewphysicians.com to be able to sign for me, 
> I would go to the wizard https://secure.winserver.com/public/wcdmarc,  enter 
> your domain in the list of authorized signers, click Zone Record and I get a 
> record I can add to my isdg.net zone:
> 
> e25dhs2vmyjf2tc2df4efpeu7js7hbik._atps  TXT ("v=atps01; 
> d=bayviewphysicians.com;")
> 
> So anyone out there can see that I authorized bayviewphysicians.com to sign 
> for isdg.net
> 
> It is really sample.
> 
> Whether we can "coerce" receivers to honor any of this is a different 
> situation.  In general, all you can do create a PROTOCOL that makes good 
> engineering sense and usable by the IETF community. If not, then generally 
> systems will ignore it.

I admittedly know nothing about ATPS, but I think its fundamental problem is 
that it authorizes 3rd parties at the domain level and that makes it not much 
better than SPF, just different.  

Email domains that have more than a few users don't want to authorize every 
potential 3rd party (converges quickly to all of them, for large/complex 
organizations) to sign as every user/address in the domain.  Even if SPF didn't 
have the 10 DNS lookup limitation, I would not choose put every 3rd party into 
our domains' SPF records.  I'd essentially be authorizing most of the 
[legitimate] internet to use the domains.

Ironically, you'll notice some domains actually doing this via SPF record 
flattening and macros specifically because they do not even want to attempt to 
solve the 3rd party authorization problem (look at umich.edu).

On the other hand, something like ATPS might be a partial solution for the MLM 
header munging problem, at least for intra-organizational email leveraging 3rd 
party platforms.  e.g. If I authorize only mlm.wisc.edu (and not every 
subdomain, so aspf=r is not an option) to send as wisc.edu (and potentially all 
of our ~480 domains which aren't all subdomains of wisc.edu), then the MLM 
platform should know that it doesn't need to rewrite the From header for 
messages from users in those domains.

It's kind of the inverse of the ARC dillemma.  ARC is missing a mechanism to 
tell an Intermediary if it will be safe to *not* rewrite the From header, and 
the lack of having a mechanism to convey historical or intended 

Re: [dmarc-ietf] non-mailing list use case for differing header domains

[Hector Santos]

On 7/30/2020 7:57 AM, Ken O'Driscoll wrote:

On 30/07/2020 11:39, Jeremy Harris wrote:

That works at a domain-controlled level.  But people sign up for,
and write to, mailinglists on an individual level.  Mismatch.


To be fair, this thread is specifically about a non-MLM use case at an
organisational level. But, I believe that any improvements to how DMARC
might handle use cases like mailing lists will likely have to be at the
domain-controlled level for there to be any chance of widespread adoption.

From experience, the type of organisations that are deploying DMARC (in
p=reject) are not interested in allowing individual senders to delegate
which third-parties can send on their behalf. Banks etc. don't care
about mailing lists, most have HR policies that prevent employees from
interacting on external discussion groups so it's not on the radar.
However,  the use case presented in this thread - executive assistants
sending on behalf of multiple DMARC protected brand domains - is not
that uncommon and I think a policy solution to that would be warmly
welcomed.


+1

--
Hector Santos,
https://secure.santronics.com
https://twitter.com/hectorsantos


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

Re: [dmarc-ietf] non-mailing list use case for differing header domains

[Hector Santos]

On 7/30/2020 6:39 AM, Jeremy Harris wrote:

On 29/07/2020 18:34, Hector Santos wrote:

Look at my DMARC record for my isdg.net domain:

v=DMARC1; p=reject; atps=y; rua=mailto:dmarc-...@isdg.net;
ruf=mailto:dmarc-...@isdg.net;

The atps=y [...]
So anyone out there can see that I authorized bayviewphysicians.com to
sign for isdg.net

It is really [simple.]


That works at a domain-controlled level.  But people sign up for,
and write to, mailinglists on an individual level.  Mismatch.


Very true. The authoring domain will need to have a way to add ATPS 
records defining who has explicit authorizing to sign/resign on behalf 
of the authorizing domain.   This will immediately help resolve a 
number of the scenarios for Authorized Third Party Signatures.


The individual user mailing list issue continues because of the use of 
restrictive domains in a public arena where there are no controls. 
There are two ways to deal with this:


1) Domain Organization policy. Does it allow its domain users to 
freely use their corporate, company domains in a public professional 
environment?


2) The MLM supported of a DKIM+DMARC+ATPS will restrict domains that 
it can not resign.


The MLM needs to be updated to support restrictive DKIM Policy domains.

--
Hector Santos,
https://secure.santronics.com
https://twitter.com/hectorsantos


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

Re: [dmarc-ietf] non-mailing list use case for differing header domains

[Ken O'Driscoll]

On 30/07/2020 11:39, Jeremy Harris wrote:
> That works at a domain-controlled level.  But people sign up for,
> and write to, mailinglists on an individual level.  Mismatch.

To be fair, this thread is specifically about a non-MLM use case at an
organisational level. But, I believe that any improvements to how DMARC
might handle use cases like mailing lists will likely have to be at the
domain-controlled level for there to be any chance of widespread adoption.

>From experience, the type of organisations that are deploying DMARC (in
p=reject) are not interested in allowing individual senders to delegate
which third-parties can send on their behalf. Banks etc. don't care
about mailing lists, most have HR policies that prevent employees from
interacting on external discussion groups so it's not on the radar.
However,  the use case presented in this thread - executive assistants
sending on behalf of multiple DMARC protected brand domains - is not
that uncommon and I think a policy solution to that would be warmly
welcomed.

Ken.

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

Re: [dmarc-ietf] non-mailing list use case for differing header domains

[Jeremy Harris]

On 29/07/2020 18:34, Hector Santos wrote:
> Look at my DMARC record for my isdg.net domain:
> 
> v=DMARC1; p=reject; atps=y; rua=mailto:dmarc-...@isdg.net;
> ruf=mailto:dmarc-...@isdg.net;
> 
> The atps=y [...]
> So anyone out there can see that I authorized bayviewphysicians.com to
> sign for isdg.net
> 
> It is really sample.

That works at a domain-controlled level.  But people sign up for,
and write to, mailinglists on an individual level.  Mismatch.
-- 
Cheers,
  Jeremy

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

Re: [dmarc-ietf] non-mailing list use case for differing header domains

[Douglas E. Foster]

On the issue of spoofing, only two security postures are possible in the 
incoming mail gateway:
We allow spoofing by default, then block problematic spoofing as detected, on a 
case-by-case basis.We disallow spoofing by default, then allow desired mail as 
needed, on a case-by-case basis.
Only the second security posture is credible in a security audit.   DMARC v1 is 
the most effective tool for implementing that security posture.   The proposed 
"new" DMARC returns us to the first security posture.

Incoming email can be divided into these categories:
Messages that have confirmed identitiesMessages that appear to be spoofing but 
actually contain desired content from valued senders.Messages that appear to be 
spoofing and are unwanted.Messages where spoofing cannot be evaluated.
Security posture 2 will be associated with these policies:
Message category 1 will be allowed or blocked on other criteria.In 
particular, confirmed identity allows preferred message handling to be 
implemented safely.Message category 2 will be handled through the receiving 
organization's exception process.   Message category 3 will always be blocked.  
  Message category 4 may be reviewed, as time permits, to determine a local 
policy which moves it into category 1 or 3.
If there are category 2 problem cannot be solved between a recipient user and 
his email security team, we need to document when and why this is happening,

However, the expectation is that senders in category 2 and 4 will have 
incentive to move into category 1 over time.   To the extent that this has not 
happened, it is a great misfortune.

An excess of category 2 messages can contribute to an organization choosing to 
delay or abandon implementation of security posture 2.   This increases their 
risk.   Indirectly, category 2 messages serve to facilitate the dirty work of 
category 3 messages, in exactly the same way that a large enough crowd can 
become an enabler for looters and arsonists.

DF


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

Re: [dmarc-ietf] non-mailing list use case for differing header domains

[Hector Santos]

On 7/28/2020 1:19 PM, Doug Foster wrote:

Hector, I do not understand this comment:

"The DKIM Policy Model since ADSP lacked the ability to authorize 3rd party domains. 
DMARC did not address the problem and reason ADSP was abandoned. Hence the on-going 
dilemma."



SSP, ADSP and DMARC are technical specs for a DKIM POLICY Model.

The problem we have with DMARC was the same with SSP which was 
replaced by ADSP which attempted to ignore the problem. Generally, as 
it often done with ambiguous issues in the IETF, we ignore it, we make 
it out of scope, we keep it open ended, etc.  It just wasn't resolved 
and ADSP was abandoned but returned as DMARC but it also kept the same 
3rd party ignorance as ADSP did.   If this issue is not resolved for 
DMARC, I see an interesting situation during DMARCBis Last Call 
explaining how we abandoned ADSP for having problem XYZ and then 
reintroduced "SUPER ADSP" as DMARC but it still has the problem XYZ.



Domains that participate with a mailing list have the option of including the 
ML servers in their SPF record, or delegating them a DKIM scope and key.But 
to obtain that authorization from the sending domain, someone would have to ask 
for it, and might not receive the desired answer.

The goal of this discussion is to find a way to coerce trust.   We do not lack 
ways to grant trust on request.


This issue is not about the known, but the unknown. We don't have an 
issue with proactive authorization and whitelisting methods.


I've been in this DKIM project for 15+ years, and to me, the goal has 
also been to find a reasonable, scalable deterministic protocol that 
will handle unsolicited, unknown 3rd party domain signers. Not 
necessarily unknown in a bad sense, unknown that you don't know 
anything about them. So you ask the author, "Hey, is this 3rd party 
signer ok?"


SPF allows 3rd party IP declarations.  DKIM POLICY model does not 
offer this capability.


We have DKIM Policy extension proposals like ATPS (RFC6541) that 
offers a deterministic method to associate the author domain with 3rd 
party signer domains.   This authorization is defined by the 
Originating, Author Domain.


Look at my DMARC record for my isdg.net domain:

v=DMARC1; p=reject; atps=y; rua=mailto:dmarc-...@isdg.net; 
ruf=mailto:dmarc-...@isdg.net;


The atps=y tells an ATPS compliant receiver that if it sees a 3rd 
party domain signature:


  Author Domain IS NOT EQUAL TO Signer Domain

Then it can do a ATPS look:

   base32(sha1(SIGNER-DOMAIN))._atps.isdg.net

So if I wanted to authorized bayviewphysicians.com to be able to sign 
for me, I would go to the wizard 
https://secure.winserver.com/public/wcdmarc,  enter your domain in the 
list of authorized signers, click Zone Record and I get a record I can 
add to my isdg.net zone:


e25dhs2vmyjf2tc2df4efpeu7js7hbik._atps  TXT ("v=atps01; 
d=bayviewphysicians.com;")


So anyone out there can see that I authorized bayviewphysicians.com to 
sign for isdg.net


It is really sample.

Whether we can "coerce" receivers to honor any of this is a different 
situation.  In general, all you can do create a PROTOCOL that makes 
good engineering sense and usable by the IETF community. If not, then 
generally systems will ignore it.



--
Hector Santos,
https://secure.santronics.com
https://twitter.com/hectorsantos


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

Re: [dmarc-ietf] non-mailing list use case for differing header domains

[Laura Atkins]

> On 29 Jul 2020, at 13:46, Todd Herr  
> wrote:
> 
> 
> 
> On Wed, Jul 29, 2020 at 6:55 AM Laura Atkins  > wrote:
> 
> I’m not sure why deliverability people are even mentioned here. The problems 
> with DMARC primarily affect one-to-one or one-to-few mails, not bulk mails. 
> The breakage DMARC causes doesn’t really affect marketing, newsletters or 
> anything else sent through automated systems. I mean, yeah, some folks aren’t 
> going to get their bulk mails because of DMARC failures but mail fails all 
> the times for lots of different reasons. 
> 
> Perhaps Autumn's use case and its mention of a bank that can't do DKIM 
> signing lead me down a path that may never be followed.

I don’t think the bank is sending mail that isn’t DKIM signed, I think DKIM 
signatures have the same inherent alignment failure of SPF - where the admin 
assistant sends out a MTA for their business unit/domain but uses the From: 
address of an executive of a different business unit. That MTA signs for the 
domain it is supposed to sign for. Possible my assumption was incorrect. 
 
> Where my mind went was to a place where an ESP was employed by a brand to 
> send mail, either bulk or transactional (or both), and such mail was sent 
> with the ESP domain as the domain in the "Sender:" field and the brand's 
> domain as the domain in the "From:" field (or vice versa), with each domain 
> publishing DMARC records. In such a scenario, it's possible that conflicting 
> DMARC validation results could occur, leading to the concern over how such 
> things might be handled.

There will possibly be places where folks will choose to use Sender for ESPs, 
but most ESPs are currently willing and able to provide alignment for their 
customers. I can’t really see the ESP wanting to step into the sender role here 
particularly when their customers are already aligned. I can also envision a 
situation where the ESP doesn’t want to be the sender because that may impact 
their legal liability and responsibilities. 

Longer term, though, this could actually be really beneficial for companies who 
are using ESPs but can’t, for whatever reason, align their mail at the ESP. The 
ESP can step in as “sender” (where sender is 
customername@espalignmentdomain.example) and have that DMARC align. Right now 
it’s not an issue as there is no delivery hit for sending mail without a DMARC 
policy statement. But, if we ever get to the point where p=quarantine or 
p=reject is required for delivery, the ESP can handle that for their customers 
using the Sender: header. 

On the other hand, this would solve the problem where so many small business 
owners and ad hoc groups got shut out of using ESPs when Yahoo! sprung p=reject 
on the world. The ESP could use the Sender: field and it doesn’t matter that 
the mail wouldn’t align with Yahoo. I do remember hearing at one point some of 
the big commercial groups were including ESP outbounds in their SPF records to 
compensate, so this would be less overhead. 

Need to think about that a little bit because I can see some potential attack 
vectors. 

> If this is not a possible use case for these header fields, then please 
> accept my apologies for bringing deliverability into the discussion.

I hadn’t thought about this for ESP mediated mail. But you have made me think a 
little harder about it. 

laura 

-- 
Having an Email Crisis?  We can help! 800 823-9674 

Laura Atkins
Word to the Wise
la...@wordtothewise.com
(650) 437-0741  

Email Delivery Blog: https://wordtothewise.com/blog 







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

Re: [dmarc-ietf] non-mailing list use case for differing header domains

[Todd Herr]

On Wed, Jul 29, 2020 at 6:55 AM Laura Atkins 
wrote:

>
> I’m not sure why deliverability people are even mentioned here. The
> problems with DMARC primarily affect one-to-one or one-to-few mails, not
> bulk mails. The breakage DMARC causes doesn’t really affect marketing,
> newsletters or anything else sent through automated systems. I mean, yeah,
> some folks aren’t going to get their bulk mails because of DMARC failures
> but mail fails all the times for lots of different reasons.
>
>
>
Perhaps Autumn's use case and its mention of a bank that can't do DKIM
signing lead me down a path that may never be followed.

Where my mind went was to a place where an ESP was employed by a brand to
send mail, either bulk or transactional (or both), and such mail was sent
with the ESP domain as the domain in the "Sender:" field and the brand's
domain as the domain in the "From:" field (or vice versa), with each domain
publishing DMARC records. In such a scenario, it's possible that
conflicting DMARC validation results could occur, leading to the concern
over how such things might be handled.

If this is not a possible use case for these header fields, then please
accept my apologies for bringing deliverability into the discussion.

-- 

*Todd Herr* | Sr. Technical Program Manager
*e:* todd.h...@valimail.com
*p:* 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] non-mailing list use case for differing header domains

[Laura Atkins]

> On 28 Jul 2020, at 23:54, John R Levine  wrote:
> 
 Which verdict gets applied to the message?
>>> 
>>> I believe the reasoanble answer is both, and the filtering engine
>>> evaluates both based on their reputations.
>>> 
>> Two responses, two different but equally valid answers, the other (Dave's)
>> being "receiver discretion", which *could* be an umbrella term to include
>> John's answer, but would certainly also include other applications of rules
>> for this scenario.
> 
> I think Dave and I are agreeing here.  Assume I mean reputation in a very 
> broad sense.
> 
>> will be wailed, teeth will be gnashed, and garments will be rent,
>> especially among those trying to do the right thing when sending email and
>> the deliverability people they employ.
> 
> I said to Autumn, I expect the number of people sending mail with Sender 
> DMARC will be so small that the deliverability people won't notice.  And, of 
> course, receivers will continue to do as they d* please, same as we've done 
> for 40 years.

I’m not sure why deliverability people are even mentioned here. The problems 
with DMARC primarily affect one-to-one or one-to-few mails, not bulk mails. The 
breakage DMARC causes doesn’t really affect marketing, newsletters or anything 
else sent through automated systems. I mean, yeah, some folks aren’t going to 
get their bulk mails because of DMARC failures but mail fails all the times for 
lots of different reasons. 

DMARC broke how a lot of people and corporations use email as a communication 
medium and I, for one, welcome the attempts to finally address the fallout. I 
think if these issues are addressed more comprehensively you’ll see a much 
bigger adoption for DMARC, particularly among larger companies. 

laura 

-- 
Having an Email Crisis?  We can help! 800 823-9674 

Laura Atkins
Word to the Wise
la...@wordtothewise.com
(650) 437-0741  

Email Delivery Blog: https://wordtothewise.com/blog 







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

Re: [dmarc-ietf] non-mailing list use case for differing header domains

[Alessandro Vesely]

On Tue 28/Jul/2020 23:23:24 +0200 John R Levine wrote, quoting Autumn:
To Todd's point, I think the answer on which policy would be applied at least 
needs to be predictable. If one receiver chooses one policy and a different 
receiver chooses the other policy, that is going to make it significantly 
more complicated for complex organizations to implement a DMARC p=reject or 
even p=quarantine policy.


But it's not predictable now.  Some receivers follow p=reject all the time, 
some follow it sometimes, some follow it never (me.)



I follow it sometimes, but it would be easier to follow it always.  If it were 
set up correctly, the latter would also be more reliable.


To suggest disposition, I'd add an "snd=" tag in the From: domain's DMARC 
record, having one of the following values:


*none*: Sender: field shall not be considered for messages From: this domain. 
This should be the default, for compatibility with existing settings.


*any*: Accept messages forwarded by any Sender:, provided it validates.

*/reputation domain/*: Supply a domain to be looked up for Sender: reputation. 
If Sender: validates and has a positive reputation, then accept the message.



I think that in practice the situations where someone else is going to resign 
your mail with a Sender DMARC policy are narrow enough that most IT departments 
wouldn't even notice.



Except if setting Sender: to the next trash domain becomes an attack path for 
phishing.



Best
Ale
--




























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

Re: [dmarc-ietf] non-mailing list use case for differing header domains

[Alessandro Vesely]

On Tue 28/Jul/2020 19:19:50 +0200 Doug Foster wrote:
> Hector, I do not understand this comment:
> 
>> "The DKIM Policy Model since ADSP lacked the ability to authorize 3rd party 
>> domains. DMARC did not address the problem and reason ADSP was abandoned. 
>> Hence the on-going dilemma."
> 
> Domains that participate with a mailing list have the option of including the 
> ML servers in their SPF record, or delegating them a DKIM scope and key.
> But to obtain that authorization from the sending domain, someone would have 
> to ask for it, and might not receive the desired answer.


It is difficult, even for smallish domains, to get a complete list of MLMs 
which legitimately distribute messages From: their users.


> The goal of this discussion is to find a way to coerce trust.   We do not 
> lack ways to grant trust on request.


Right, a possible approach is to outsource trust.  If you lookup my SPF 
record[*] you can see an example.


Best
Ale
-- 

[*] "v=spf1 +ip4:62.94.243.226 ?exists:%{ir}.list.dnswl.org -all"














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

Re: [dmarc-ietf] non-mailing list use case for differing header domains

[John R Levine]

Which verdict gets applied to the message?


I believe the reasoanble answer is both, and the filtering engine
evaluates both based on their reputations.


Two responses, two different but equally valid answers, the other (Dave's)
being "receiver discretion", which *could* be an umbrella term to include
John's answer, but would certainly also include other applications of rules
for this scenario.


I think Dave and I are agreeing here.  Assume I mean reputation in a very 
broad sense.



will be wailed, teeth will be gnashed, and garments will be rent,
especially among those trying to do the right thing when sending email and
the deliverability people they employ.


I said to Autumn, I expect the number of people sending mail with Sender 
DMARC will be so small that the deliverability people won't notice.  And, 
of course, receivers will continue to do as they d* please, same as we've 
done for 40 years.


Regards,
John Levine, jo...@taugh.com, Taughannock Networks, Trumansburg NY
Please consider the environment before reading this e-mail. https://jl.ly

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

Re: [dmarc-ietf] non-mailing list use case for differing header domains

[John R Levine]

To Todd's point, I think the answer on which policy would be applied at 
least needs to be predictable. If one receiver chooses one policy and a 
different receiver chooses the other policy, that is going to make it 
significantly more complicated for complex organizations to implement a 
DMARC p=reject or even p=quarantine policy.


But it's not predictable now.  Some receivers follow p=reject all the 
time, some follow it sometimes, some follow it never (me.)


I think that in practice the situations where someone else is going to 
resign your mail with a Sender DMARC policy are narrow enough that most IT 
departments wouldn't even notice.


Regards,
John Levine, jo...@taugh.com, Taughannock Networks, Trumansburg NY
Please consider the environment before reading this e-mail. https://jl.ly

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

Re: [dmarc-ietf] non-mailing list use case for differing header domains

[Dave Crocker]

On 7/28/2020 2:11 PM, Autumn Tyr-Salvia wrote:
To Todd's point, I think the answer on which policy would be applied 
at least needs to be predictable. If one receiver chooses one policy 
and a different receiver chooses the other policy, that is going to 
make it significantly more complicated for complex organizations to 
implement a DMARC p=reject or even p=quarantine policy. 


I'll suggest that this needs to be less a normative specification and 
more a best practices write-up.  First, as I've noted, receivers will do 
whatever they want.  Second is that I believe we don't yet know the 
better answers.  (And so, really, I don't mean a BCP, but rather a 
'considerations' doc.)


d/

--
Dave Crocker
Brandenburg InternetWorking
bbiw.net

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

Re: [dmarc-ietf] non-mailing list use case for differing header domains

[Todd Herr]

On Tue, Jul 28, 2020 at 5:11 PM Autumn Tyr-Salvia  wrote:

> To Todd's point, I think the answer on which policy would be applied at
> least needs to be predictable. If one receiver chooses one policy and a
> different receiver chooses the other policy, that is going to make it
> significantly more complicated for complex organizations to implement a
> DMARC p=reject or even p=quarantine policy.
>
>
Yes, yes it very much will.

-- 

*Todd Herr* | Sr. Technical Program Manager
*e:* todd.h...@valimail.com
*p:* 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] non-mailing list use case for differing header domains

[Autumn Tyr-Salvia]

To Todd's point, I think the answer on which policy would be applied at least 
needs to be predictable. If one receiver chooses one policy and a different 
receiver chooses the other policy, that is going to make it significantly more 
complicated for complex organizations to implement a DMARC p=reject or even 
p=quarantine policy.


Thanks,

Autumn Tyr-Salvia
atyrsal...@agari.com
Agari Principal Customer Success Engineer



From: dmarc  on behalf of Todd Herr 

Sent: Tuesday, July 28, 2020 1:58 PM
To: John R Levine 
Cc: IETF DMARC WG 
Subject: Re: [dmarc-ietf] non-mailing list use case for differing header domains



On Tue, Jul 28, 2020 at 4:30 PM John R Levine 
mailto:jo...@taugh.com>> wrote:
On Tue, 28 Jul 2020, Todd Herr wrote:
> Using the Sender header and the "snd" bits in the DMARC policy for
> firstbrand.com<https://nam12.safelinks.protection.outlook.com/?url=http%3A%2F%2Ffirstbrand.com%2F=02%7C01%7Catyrsalvia%40agari.com%7C92171061501e4c0b556008d833390787%7C05773123385e420d844ef01aee5e37ab%7C0%7C0%7C637315667319827245=1AHw64v72T7eJ%2BNrnkkUsSnky%2F1H2CqV3tA1t1X0FvM%3D=0>,
>  DMARC would pass for the Sender domain and fail for the
> From domain.
>
> Which verdict gets applied to the message?

I believe the reasoanble answer is both, and the filtering engine
evaluates both based on their reputations.


Two responses, two different but equally valid answers, the other (Dave's) 
being "receiver discretion", which *could* be an umbrella term to include 
John's answer, but would certainly also include other applications of rules for 
this scenario.

Note that I'm not at all opposed to the idea put forth in 
https://datatracker.ietf.org/doc/draft-crocker-dmarc-sender/<https://nam12.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fdraft-crocker-dmarc-sender%2F=02%7C01%7Catyrsalvia%40agari.com%7C92171061501e4c0b556008d833390787%7C05773123385e420d844ef01aee5e37ab%7C0%7C0%7C637315667319827245=6Z2zUXQD8CB14mF9Tw9bNDVb7k5dyqUAez%2BJ%2B8TPYUs%3D=0>
 but I do believe that there will have to evolve a very limited set of known 
and expected possibilities for how such messages will be handled, or else wails 
will be wailed, teeth will be gnashed, and garments will be rent, especially 
among those trying to do the right thing when sending email and the 
deliverability people they employ.

--

Todd Herr | Sr. Technical Program Manager
e: todd.h...@valimail.com<mailto:todd.h...@valimail.com>
p: 703.220.4153

[https://lh5.googleusercontent.com/_vs__6iRjfmT2Ae5LLNBb8nEopl2M5Tl5QlpS6LS0Lh0vv4TYnZu-Mff2kDFOqe0LhbnSXprAx4yoaTvq_Tc_7n1b8yzGIqoxuhedthDxYQansg8ChT2x5EcZV3rjz19-Dx9rESL]


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] non-mailing list use case for differing header domains

[Todd Herr]

On Tue, Jul 28, 2020 at 4:30 PM John R Levine  wrote:

> On Tue, 28 Jul 2020, Todd Herr wrote:
> > Using the Sender header and the "snd" bits in the DMARC policy for
> > firstbrand.com, DMARC would pass for the Sender domain and fail for the
> > From domain.
> >
> > Which verdict gets applied to the message?
>
> I believe the reasoanble answer is both, and the filtering engine
> evaluates both based on their reputations.
>
>
Two responses, two different but equally valid answers, the other (Dave's)
being "receiver discretion", which *could* be an umbrella term to include
John's answer, but would certainly also include other applications of rules
for this scenario.

Note that I'm not at all opposed to the idea put forth in
https://datatracker.ietf.org/doc/draft-crocker-dmarc-sender/ but I do
believe that there will have to evolve a very limited set of known and
expected possibilities for how such messages will be handled, or else wails
will be wailed, teeth will be gnashed, and garments will be rent,
especially among those trying to do the right thing when sending email and
the deliverability people they employ.

-- 

*Todd Herr* | Sr. Technical Program Manager
*e:* todd.h...@valimail.com
*p:* 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] non-mailing list use case for differing header domains

[John R Levine]

On Tue, 28 Jul 2020, Todd Herr wrote:

Using the Sender header and the "snd" bits in the DMARC policy for
firstbrand.com, DMARC would pass for the Sender domain and fail for the
From domain.

Which verdict gets applied to the message?


I believe the reasoanble answer is both, and the filtering engine 
evaluates both based on their reputations.


Regards,
John Levine, jo...@taugh.com, Taughannock Networks, Trumansburg NY
Please consider the environment before reading this e-mail. https://jl.ly

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

Re: [dmarc-ietf] non-mailing list use case for differing header domains

[Dave Crocker]

On 7/28/2020 1:13 PM, Todd Herr wrote:


On Tue, Jul 28, 2020 at 1:37 PM John Levine > wrote:


The canonical example of different From and Sender is exactly this:
Sender is an assistant working for and sending mail for From.

This is also precisely the situation I asked about during the session 
on Dave's sender proposal.


And it is exactly the reason RFC 733 defined two different header fields.


Using the Sender header and the "snd" bits in the DMARC policy for 
firstbrand.com , DMARC would pass for the 
Sender domain and fail for the From domain.


Which verdict gets applied to the message?


DMARC is written with the view that receivers will follow the directive 
in the domain owner's DMARC record, but really the receiver has complete 
discretion, and many receivers exercise that interpretive freedom.


So the answer to your question needs to be: the receiver needs to juggle 
these bits of information and decide what action to take. It's what they 
do, anyhow.


This isn't something that has a simple, obvious answer that is always 
correct.  So leave it as a matter of receiver discretion. Especially 
since that's what it actually is.


d/

--
Dave Crocker
Brandenburg InternetWorking
bbiw.net

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

Re: [dmarc-ietf] non-mailing list use case for differing header domains

[Todd Herr]

On Tue, Jul 28, 2020 at 1:37 PM John Levine  wrote:

> In article <
> by5pr13mb29998094418c8a6c25902569d7...@by5pr13mb2999.namprd13.prod.outlook.com>
> you write:
> >To put it another way:
> >
> >  *   assist...@firstbrand.com is organizing a meeting for
> execut...@secondbrand.com
> >  *   assist...@firstbrand.com sends out a calendar invite from their
> own messaging client, using
> >execut...@secondbrand.com in the From: field
> >  *   The resulting message uses execut...@secondbrand.com in the
> friendly From: field, but firstbrand.com in the
> >SMTP MAIL FROM domain, so the headers are no longer aligned for SPF.
> >  *   Both firstbrand.com and secondbrand.com are set to DMARC p=reject.
> >  *   Messages like this are then rejected by receivers that validate
> DMARC results.
>
> This sounds like an excellent use case for Dave's
> draft-crocker-dmarc-sender proposal.
>
> The canonical example of different From and Sender is exactly this:
> Sender is an assistant working for and sending mail for From.
>
>
>
This is also precisely the situation I asked about during the session on
Dave's sender proposal.

Using the Sender header and the "snd" bits in the DMARC policy for
firstbrand.com, DMARC would pass for the Sender domain and fail for the
>From domain.

Which verdict gets applied to the message?

-- 

*Todd Herr* | Sr. Technical Program Manager
*e:* todd.h...@valimail.com
*p:* 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] non-mailing list use case for differing header domains

[Jesse Thompson]

On 7/28/20 10:59 AM, Alessandro Vesely wrote:
> I understood the problem is the lack of agility.  Delegation to smaller 
> domains using local servers would solve it, wouldn't it?  Even with many 
> domains...
> 
> What am I missing?

It's assuming there are local servers in the mix, which is becoming less common 
with the shift to the cloud.  e.g, I am fairly certain that O365 doesn't have 
the DKIM flexibility you're talking about.

Jesse

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

Re: [dmarc-ietf] non-mailing list use case for differing header domains

[John Levine]

In article 

 you write:
>To put it another way:
>
>  *   assist...@firstbrand.com is organizing a meeting for 
> execut...@secondbrand.com
>  *   assist...@firstbrand.com sends out a calendar invite from their own 
> messaging client, using
>execut...@secondbrand.com in the From: field
>  *   The resulting message uses execut...@secondbrand.com in the friendly 
> From: field, but firstbrand.com in the
>SMTP MAIL FROM domain, so the headers are no longer aligned for SPF.
>  *   Both firstbrand.com and secondbrand.com are set to DMARC p=reject.
>  *   Messages like this are then rejected by receivers that validate DMARC 
> results.

This sounds like an excellent use case for Dave's draft-crocker-dmarc-sender 
proposal.

The canonical example of different From and Sender is exactly this:
Sender is an assistant working for and sending mail for From.

R's,
John

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

Re: [dmarc-ietf] non-mailing list use case for differing header domains

[Doug Foster]

Hector, I do not understand this comment:

"The DKIM Policy Model since ADSP lacked the ability to authorize 3rd party 
domains. DMARC did not address the problem and reason ADSP was abandoned. Hence 
the on-going dilemma."

Domains that participate with a mailing list have the option of including the 
ML servers in their SPF record, or delegating them a DKIM scope and key.But 
to obtain that authorization from the sending domain, someone would have to ask 
for it, and might not receive the desired answer.

The goal of this discussion is to find a way to coerce trust.   We do not lack 
ways to grant trust on request.




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

Re: [dmarc-ietf] non-mailing list use case for differing header domains

[Hector Santos]

On 7/28/2020 5:07 AM, Laura Atkins wrote:


The indirect mail stream issue is real. But it is not the only barrier
to getting to p=reject. The sooner folks start listening to the people
who are presenting real issues where DMARC alignment can’t be achieved
the sooner they’ll be able to address them. The problem with low DMARC
adoption is that it does not adequately address how companies are
using mail in ways that break the DMARC model. Almost a decade on, and
proponents are still suggesting that email usage should change to
comply with their model of how email works. This has not happened.
Maybe proponents need to think harder about why.


Well said.

It has always been how do we scale a "Lightweight Author::Signer 
Authorization Protocol" or LASAP methodology.  Examples of LASAP are:


ATPS
TPA
Conditional Signatures

SPF offers 3rd party (associated, authorized) IP addresses and does 
not have this problem (administration aside).  The DKIM Policy Model 
since ADSP lacked the ability to authorize 3rd party domains. DMARC 
did not address the problem and reason ADSP was abandoned. Hence the 
on-going dilemma.



--
Hector Santos,
https://secure.santronics.com
https://twitter.com/hectorsantos


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

Re: [dmarc-ietf] non-mailing list use case for differing header domains

[Alessandro Vesely]

On Tue 28/Jul/2020 17:22:41 +0200 Laura Atkins wrote:

On 28 Jul 2020, at 16:14, Alessandro Vesely wrote:
On Tue 28/Jul/2020 11:07:19 +0200 Laura Atkins wrote:

On 28 Jul 2020, at 08:36, Alessandro Vesely wrote:
On Tue 28/Jul/2020 08:54:02 +0200 Autumn Tyr-Salvia wrote:



# The resulting message uses execut...@secondbrand.com in the
friendly From: field, but firstbrand.com   in
the SMTP MAIL FROM domain, so the headers are no longer aligned for
SPF. 

Heck, can't they DKIM sign?

This really misses Autumn’s point. [...]
Autumn has presented a very real world scenario that demonstrates the
overall complexity of mail management operationally. Your solution “sign
with DKIM” has significant barriers to adoption. For instance, assume that
there is code installed on the mailserver that will grab the 5322.from
address and sign with the appropriate DKIM key. How many domains are
involved? How many different mailservers? How long will this solution take
to deploy? Banks do not move quickly and, for the obvious reasons, any
changes to security require multiple reviews and assurances that the
implications are understood.



If the bank delegates a subdomain to each trusted subsidiary, each
subsidiary could manage their keys on their local DNS and email servers.
If the bank can afford "relaxed" DKIM alignment, they can sign with 
d=local-branch.bank.example and From: transactions@bank.example. What's

the risk of doing so? >

That does not address the problem Autumn brought up at all.



I understood the problem is the lack of agility.  Delegation to smaller domains 
using local servers would solve it, wouldn't it?  Even with many domains...


What am I missing?


Best
Ale
--























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

Re: [dmarc-ietf] non-mailing list use case for differing header domains

[Laura Atkins]

> On 28 Jul 2020, at 16:14, Alessandro Vesely  wrote:
> 
> On Tue 28/Jul/2020 11:07:19 +0200 Laura Atkins wrote:
>>> On 28 Jul 2020, at 08:36, Alessandro Vesely >> On Tue 28/Jul/2020 08:54:02 +0200 Autumn Tyr-Salvia wrote:
> 
 # The resulting message uses execut...@secondbrand.com in the friendly
 From: field, but firstbrand.com  in the SMTP MAIL FROM domain, so the 
 headers are no longer aligned for SPF. >>> #
>>> 
>>> Heck, can't they DKIM sign?
>> This really misses Autumn’s point. [...]
>> Autumn has presented a very real world scenario that demonstrates the
>> overall complexity of mail management operationally. Your solution “sign
>> with DKIM” has significant barriers to adoption. For instance, assume that
>> there is code installed on the mailserver that will grab the 5322.from
>> address and sign with the appropriate DKIM key. How many domains are
>> involved? How many different mailservers? How long will this solution take
>> to deploy? Banks do not move quickly and, for the obvious reasons, any
>> changes to security require multiple reviews and assurances that the
>> implications are understood.
> 
> 
> If the bank delegates a subdomain to each trusted subsidiary, each subsidiary 
> could manage their keys on their local DNS and email servers.  If the bank 
> can afford "relaxed" DKIM alignment, they can sign with 
> d=local-branch.bank.example and From: transactions@bank.example.  What's the 
> risk of doing so?

That does not address the problem Autumn brought up at all. 

laura 

-- 
Having an Email Crisis?  We can help! 800 823-9674 

Laura Atkins
Word to the Wise
la...@wordtothewise.com
(650) 437-0741  

Email Delivery Blog: https://wordtothewise.com/blog 







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

Re: [dmarc-ietf] non-mailing list use case for differing header domains

[Alessandro Vesely]

On Tue 28/Jul/2020 11:07:19 +0200 Laura Atkins wrote:

On 28 Jul 2020, at 08:36, Alessandro Vesely 


# The resulting message uses execut...@secondbrand.com in the friendly
From: field, but firstbrand.com  in the SMTP MAIL FROM domain, so the 
headers are no longer aligned for SPF. >>> #


Heck, can't they DKIM sign?


This really misses Autumn’s point. [...]

Autumn has presented a very real world scenario that demonstrates the
overall complexity of mail management operationally. Your solution “sign
with DKIM” has significant barriers to adoption. For instance, assume that
there is code installed on the mailserver that will grab the 5322.from
address and sign with the appropriate DKIM key. How many domains are
involved? How many different mailservers? How long will this solution take
to deploy? Banks do not move quickly and, for the obvious reasons, any
changes to security require multiple reviews and assurances that the
implications are understood.



If the bank delegates a subdomain to each trusted subsidiary, each subsidiary 
could manage their keys on their local DNS and email servers.  If the bank can 
afford "relaxed" DKIM alignment, they can sign with d=local-branch.bank.example 
and From: transactions@bank.example.  What's the risk of doing so?



Best
Ale
--





























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

Re: [dmarc-ietf] non-mailing list use case for differing header domains

[Douglas E. Foster]

Calender invites are a known issue, and the issue is mentioned in RFC 7960.

The exact scenario is:
User A creates a meeting and invites User B who is in a different email 
domain.User B forwards the invite to User C, who is in a different 
administrative domain than User B.  The invite is sent using User A as the 
sender, so the invite fails DMARC tests.
The problem does not occur if User A extends the invite to User C.
The problem does not occur if User B and User C are in the same administrative 
domain,on the assumption that DMARC is not checked or enforced on messages that 
are internal to the administrative domain.

For invitations that are relayed across administrative boundaries within the 
organization, email filtering exceptions should work around the problem.  If 
not, the organization needs a different email filtering product.

For invitations that are relayed outside the organization, the policy of the 
receiving domain will determine whether the message is blocked or allowed..  I 
would expect that most DMARC enforcers have encountered this problem and have 
developed a workaround to it.

Or course, this WG or a spinoff could investigate ways for cooperating MUAs, to 
send invites that do not encounter this problem.

As Laura Atkins said, DMARC implementation is not easy.  Nonetheless, 
deployment is slowly increasing, not decreasing.It seems unlikely that 
DMARC enforcement will go away.


From: atyrsalvia=40agari@dmarc.ietf.org
Sent: 7/28/20 2:54 AM
To: "dmarc@ietf.org" 
Subject: [dmarc-ietf] non-mailing list use case for differing header domains
Hello,

I recently had a conversation with Dave Crocker about proposed changes for 
DMARC, and mentioned a use case to him that is not well served by the current 
situation that is not a mailing list. He said it might be useful to share this 
to this list, so I'm writing it out here.

A customer of mine is a large financial services company. Like many in that 
field, they have acquired several other companies over the years, and now 
operate multiple different brands, which send email using different domains... 
While many companies like this maintain one primary domain for corporate email 
and others only for marketing purposes, this company maintains multiple 
distinct domains even for corporate workplace email.

The challenge is that they have many administrative assistants who send out 
meeting calendar invitations on behalf of the executives they support, and the 
executive and the assistant do not always use the same email domain. The 
resulting messages are not aligned, so they fail DMARC.

To put it another way:
assist...@firstbrand.com is organizing a meeting for 
executive@secondbrand.comassist...@firstbrand.com sends out a calendar invite 
from their own messaging client, using execut...@secondbrand.com in the From: 
fieldThe resulting message uses execut...@secondbrand.com in the friendly From: 
field, but firstbrand.com in the SMTP MAIL FROM domain, so the headers are no 
longer aligned for SPF.Both firstbrand.com and secondbrand.com are set to DMARC 
p=reject.Messages like this are then rejected by receivers that validate DMARC 
results.

Whenever possible, they tell me they change the assistant's email domain to 
match the executives they support, but as people leave or change departments, 
they sometimes end up with assistants supporting executives across multiple 
different domains, so they can't ensure they always have the same domain.

Maybe the ultimate answer for this customer and others in a similar situation 
is simply that this is a use case that can no longer be supported due to 
evolving security needs, and yet if that's the case, I thought it would be 
helpful to share a real world scenario that is currently impacted that isn't 
part of the previously existing discussion around mailing lists.

Thanks,

Autumn Tyr-Salvia
atyrsal...@agari.com
Agari Principal Customer Success Engineer


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

Re: [dmarc-ietf] non-mailing list use case for differing header domains

[Laura Atkins]

> On 28 Jul 2020, at 08:36, Alessandro Vesely  wrote:
> 
> On Tue 28/Jul/2020 08:54:02 +0200 Autumn Tyr-Salvia wrote:
>> # The resulting message uses execut...@secondbrand.com in the friendly From: 
>> field, but firstbrand.com in the SMTP MAIL FROM domain, so the headers are 
>> no longer aligned for SPF.
>> #
> 
> Heck, can't they DKIM sign?

This really misses Autumn’s point. The issue she brings up may be unusual but 
it a lot more common than folks think. Banks, in particular, are a host of 
underlying problems related to DNS and security. I worked with a bank a few 
years back. It took 6 weeks to identify what continent the nameserver 
controlling DNS for the subdomain we were trying to authenticate lived on. Then 
there were weeks of approvals and security sign offs in order to get a DNS 
change made so we could correct a SPF record. 3 or 4 months to get an update 
done. For the record, my clients were part of the Canadian organization and the 
name servers handling their DNS were located in Australia. 

Autumn has presented a very real world scenario that demonstrates the overall 
complexity of mail management operationally. Your solution “sign with DKIM” has 
significant barriers to adoption. For instance, assume that there is code 
installed on the mailserver that will grab the 5322.from address and sign with 
the appropriate DKIM key. How many domains are involved? How many different 
mailservers? How long will this solution take to deploy? Banks do not move 
quickly and, for the obvious reasons, any changes to security require multiple 
reviews and assurances that the implications are understood.

The underlying belief with DMARC is that mail is simple, that companies are 
monoliths with only a few brands/domains, that it is possible to know exactly 
where every message will come from. These assumptions are not and have never 
been true. Inevitably, however, when these types of issues are pointed out, 
they’re dismissed with “solutions” that aren’t actually achievable or 
maintainable. DMARC proponents have repeatedly failed to pay attention to folks 
pointing out the actual operational challenges and thus have never addressed 
the issues in any way. This is, fundamentally, why only 15% of fortune 500 
companies have adopted p=reject and why adoption rates are only increased by 5% 
last year. 

The indirect mail stream issue is real. But it is not the only barrier to 
getting to p=reject. The sooner folks start listening to the people who are 
presenting real issues where DMARC alignment can’t be achieved the sooner 
they’ll be able to address them. The problem with low DMARC adoption is that it 
does not adequately address how companies are using mail in ways that break the 
DMARC model. Almost a decade on, and proponents are still suggesting that email 
usage should change to comply with their model of how email works. This has not 
happened. Maybe proponents need to think harder about why. 

laura

-- 
Having an Email Crisis?  We can help! 800 823-9674 

Laura Atkins
Word to the Wise
la...@wordtothewise.com
(650) 437-0741  

Email Delivery Blog: https://wordtothewise.com/blog 







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

Re: [dmarc-ietf] non-mailing list use case for differing header domains

[Dotzero]

On Tue, Jul 28, 2020 at 2:54 AM Autumn Tyr-Salvia  wrote:

> Hello,
>
> I recently had a conversation with Dave Crocker about proposed changes for
> DMARC, and mentioned a use case to him that is not well served by the
> current situation that is not a mailing list. He said it might be useful to
> share this to this list, so I'm writing it out here.
>
> A customer of mine is a large financial services company. Like many in
> that field, they have acquired several other companies over the years, and
> now operate multiple different brands, which send email using different
> domains.. While many companies like this maintain one primary domain for
> corporate email and others only for marketing purposes, this company
> maintains multiple distinct domains even for corporate workplace email.
>
> The challenge is that they have many administrative assistants who send
> out meeting calendar invitations on behalf of the executives they support,
> and the executive and the assistant do not always use the same email
> domain. The resulting messages are not aligned, so they fail DMARC.
>
> To put it another way:
>
>- assist...@firstbrand.com is organizing a meeting for
>execut...@secondbrand.com
>- assist...@firstbrand.com sends out a calendar invite from their own
>messaging client, using execut...@secondbrand.com in the From: field
>- The resulting message uses execut...@secondbrand.com in the friendly
>From: field, but firstbrand.com in the SMTP MAIL FROM domain, so the
>headers are no longer aligned for SPF.
>- Both firstbrand.com and secondbrand.com are set to DMARC p=reject.
>- Messages like this are then rejected by receivers that validate
>DMARC results.
>
> Whenever possible, they tell me they change the assistant's email domain
> to match the executives they support, but as people leave or change
> departments, they sometimes end up with assistants supporting executives
> across multiple different domains, so they can't ensure they always have
> the same domain.
>
> Maybe the ultimate answer for this customer and others in a similar
> situation is simply that this is a use case that can no longer be supported
> due to evolving security needs, and yet if that's the case, I thought it
> would be helpful to share a real world scenario that is currently impacted
> that isn't part of the previously existing discussion around mailing lists.
>

There are several solutions that come to mind fairly quickly considering
that this is a financial institution. Both involve a small amount of logic
and code.

The first is to DKIM sign with signatures for both domains. This involves a
relatively small amount of code and logic. Any of the MTAs I've worked with
could do this even if there are a large number of domains involved..

The second would be to always make the From and the MailFrom consistent
(keying off of the From email address) when passing through the outbound
MTAs.

Again, a little bit of logic and coding but if this is truly a significant
problem for them then it is worth the one time effort to implement either
or both of these solutions. I've done similar sorts of logic for outbound
mail on Ironport and Momentum (MessageSystems) MTAs. Any of the open source
MTAs can easily do the same. I don't view this as something a standard
needs to fix but rather something that this particular business needs to
address because they want to keep a certain business model and practices
but also want the benefits of a "p=reject" policy assertion.

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

Re: [dmarc-ietf] non-mailing list use case for differing header domains

[Alessandro Vesely]

On Tue 28/Jul/2020 08:54:02 +0200 Autumn Tyr-Salvia wrote:
# The resulting message uses execut...@secondbrand.com in the friendly From: 
field, but firstbrand.com in the SMTP MAIL FROM domain, so the headers are no 
longer aligned for SPF.

#



Heck, can't they DKIM sign?


Best
Ale
--
























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

[dmarc-ietf] non-mailing list use case for differing header domains

[Autumn Tyr-Salvia]

Hello,

I recently had a conversation with Dave Crocker about proposed changes for 
DMARC, and mentioned a use case to him that is not well served by the current 
situation that is not a mailing list. He said it might be useful to share this 
to this list, so I'm writing it out here.

A customer of mine is a large financial services company. Like many in that 
field, they have acquired several other companies over the years, and now 
operate multiple different brands, which send email using different domains.. 
While many companies like this maintain one primary domain for corporate email 
and others only for marketing purposes, this company maintains multiple 
distinct domains even for corporate workplace email.

The challenge is that they have many administrative assistants who send out 
meeting calendar invitations on behalf of the executives they support, and the 
executive and the assistant do not always use the same email domain. The 
resulting messages are not aligned, so they fail DMARC.

To put it another way:

  *   assist...@firstbrand.com is organizing a meeting for 
execut...@secondbrand.com
  *   assist...@firstbrand.com sends out a calendar invite from their own 
messaging client, using execut...@secondbrand.com in the From: field
  *   The resulting message uses execut...@secondbrand.com in the friendly 
From: field, but firstbrand.com in the SMTP MAIL FROM domain, so the headers 
are no longer aligned for SPF.
  *   Both firstbrand.com and secondbrand.com are set to DMARC p=reject.
  *   Messages like this are then rejected by receivers that validate DMARC 
results.

Whenever possible, they tell me they change the assistant's email domain to 
match the executives they support, but as people leave or change departments, 
they sometimes end up with assistants supporting executives across multiple 
different domains, so they can't ensure they always have the same domain.

Maybe the ultimate answer for this customer and others in a similar situation 
is simply that this is a use case that can no longer be supported due to 
evolving security needs, and yet if that's the case, I thought it would be 
helpful to share a real world scenario that is currently impacted that isn't 
part of the previously existing discussion around mailing lists.


Thanks,

Autumn Tyr-Salvia
atyrsal...@agari.com
Agari Principal Customer Success Engineer

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