[dmarc-ietf] Apropos of the de-munging draft

[John R Levine]

[ sent last week but got stuck due to a laptop upgrade which helpfully 
reset all my mail settings to the defaults ]



I think that draft-kucherawy-dkim-transform-02 is getting at what I was 
originally thinking.
In my opinion, MLMs will *always* need to munge, because they will never know 
if an arbitrary
receiver will trust their non-munged mail.  Giving the receivers a way to 
un-munge (if they
can and/or want and/or trust) would be a productive path forward out of this 
situation.


We already have a couple of ways to do reversible message munging, 
starting with MIME message wrapping. In principle it works fine, in 
practice it's awful because MUAs don't show wrapped messages consistently 
and often in ways that are painful, e.g., you can see the original author 
address but there's no button you can push to respond to it.


Unwrapping a MIME attachment is a lot easier than the proposed DKIM 
unmunging but I doubt either is going to show up in MUAs any time soon. 
Perhaps you could do it in a mail gateway.


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

[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] Separating DMARC alignment validation from DMARC policy

[John Levine]

In article  you write:
>On 7/28/2020 9:59 AM, Murray S. Kucherawy wrote:
>> I think it was you that suggested having the determination of the 
>> Organizational Domain be its own distinct process.  Would that fit into 
>> the first document, or should that also be something external?
>
>I'd wish for that to be entirely outside of DMARC, because the issue and 
>the mechanism are not specific to DMARC.

Unfortunately, we all know where to find DBOUND.

I suppose now that the smoke has somewhat cleared we might take another
run at the PSL problem, trying harder not to boil the ocean.

R's,
John

PS: https://github.com/jrlevine/bound

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

Re: [dmarc-ietf] Meetecho at IETF 108

[John Levine]

In article <7fb1b50a-4557-108e-b008-235758d00...@tana.it> you write:
>At mine, the audio was disconnected right after your presentation.  (I 
>couldn't 
>hear Bron's comment).  I tried reloading and reconnecting by the spin icon in 
>the lower right corner, to no avail.

Dunno how hard this would be without breaking the crypto, but it would
be nice they could adjust the sound levels so everyone's voice is
about the same loudness. That's a standard technical trick, we had a
box that did it automagically when I was doing student radio in the
1970s.



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

Re: [dmarc-ietf] Meetecho at IETF 108

[John Levine]

In article <188ab9f5-6152-65bb-9645-d59dd7463...@crash.com> you write:
>Having to flip back and forth between the chat column and the 
>queue/participant column was awkward. Assuming I didn't miss a setting: 
>Why can't we have both shown? At least as an option on larger 
>screens/windows/devices.

I think just about everyone has a separate jabber client open and
leaves the queue visible in Meetecho. It wouldn't be very hard to
provide an option to pop one or the other out into a separate window.

Also, I found it hard to tell when my mike was live. (For video at
least I could see myself.) The hint is that my name turns green at the
top of the queue column and there are some icons next to it, but I
could use clearer unobscured hints.

To repeat a point a zillion other people have been made, the tool tips
should look like they do in every other web site rather than all
appearing in a box nowhere near what you're mousing over.

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

Re: [dmarc-ietf] Fwd: New Version Notification for draft-crocker-dmarc-sender-01.txt

[John Levine]

In article  you write:
>In the pre-DMARC era, we've been mainly using just From:.  Sender: is used by 
>Outlook to display "on behalf of" catchphrase, presumably in an attempt to 
>support the historic Sender-Id protocol. 

Sorry, no. That is completely wrong. The Sender field has been part of
e-mail since RFC 724 in 1977. The now-dead Sender-ID didn't come along
until the 2000s. Outlook's annoying "on behalf of" at least matches the
intention of the Sender field.

This might be a good time to read up on mail history rather than guessing.

R's,
John

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

Re: [dmarc-ietf] Separating DMARC alignment validation from DMARC policy

[Dave Crocker]

On 7/28/2020 9:59 AM, Murray S. Kucherawy wrote:
I think it was you that suggested having the determination of the 
Organizational Domain be its own distinct process.  Would that fit into 
the first document, or should that also be something external?



I'd wish for that to be entirely outside of DMARC, because the issue and 
the mechanism are not specific to DMARC.


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 

 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] Fwd: New Version Notification for draft-crocker-dmarc-author-01.txt

[Dave Crocker]

On 7/28/2020 7:20 AM, Alessandro Vesely wrote:

On Tue 28/Jul/2020 13:09:29 +0200 Dave Crocker wrote:

On 7/28/2020 4:00 AM, Alessandro Vesely wrote:

On Tue 28/Jul/2020 12:37:32 +0200 Dave Crocker wrote:

On 7/28/2020 12:26 AM, Alessandro Vesely wrote:
Receivers can evaluate the Author: domain just like they would do 
if it were the From: domain. 


So you want to define DMARC as applying to both the From: field and 
the Author: field?  That will defeat the benefit intended for the 
Author: field.


Yes.  In case of conflict, evaluation of Author: has to be omitted.  
For example, Author: fields containing multiple mailboxes are not 
considered.


1. I don't understand the details you have in mind that would make 
this useful.



It is an optional evaluation.  It's easy to do, if you already verified 
DKIM and SPF.  It is not terribly useful, admittedly, except that having 
two or three "pass" makes for a stronger authentication than just the 
From:.  The chief reason for evaluating it is to give feedback to the MLM.


There is no specification for doing this.  It means that there is no 
basis for the creator of the Author field to expect such an 
interpretation and no basis for a receiver to apply it an expect it to 
be valid.


An interoperability standard require a shared definition of action and 
meaning.  The sharing is among the actors participating in that standard.


For one side to choose a behavior or an interpretation that is not 
documented and shared by the other participants is to pretend that a 
heuristic is more than that.






2. Again, this seems to defeat the purpose of having the Author field.



Why?


The field is intended to be free of the problematic treatment the From: 
field is now getting.  You appear to want to encumber it, so that it 
experiences those same problems.




As a new field, Author: doesn't wear a reliable-id trophy, hence 
receivers may refrain to apply policy dispositions.  However, the 
result of the evaluation, conveyed through aggregate report, can 
tell MLMs if rewriting From: was necessary.


How, exactly?


Author: and Sender: domains can be included in aggregate reports 
along with the From: one.  The policy_evaluated can also include more 
items, specifying which evaluations pass or fail.


Yes, one could modify DMARC to have its reporting include additional 
information.



d/

--
Dave Crocker
Brandenburg InternetWorking
bbiw.net

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

Re: [dmarc-ietf] Separating DMARC alignment validation from DMARC policy

[Murray S. Kucherawy]

On Tue, Jul 28, 2020 at 6:53 AM Dave Crocker  wrote:

> I am not a fan of splitting documents only for an abstract sense of
> cleanliness.  There needs to be justification of improved documentation
> 'cleanliness' and/or useful removal of fate-sharing -- if separate fates
> are reasonably expected.
>
>
> DMARC alignment validation is a basic, mechanical process that produces
> a yes/no response.  At that level, it's comparable to the nature of a
> DKIM validation, except for the From: field domain.
>
> DMARC "policy" is fundamentally different.  It's not that its mechanism
> isn't "mechanical" but that its semantics produce more semantic and
> operational challenges.
>
>
> I think that could reasonably make it worth strongly separating them
> into two different documents, no matter has small one of the documents
> might be.
>

I think it was you that suggested having the determination of the
Organizational Domain be its own distinct process.  Would that fit into the
first document, or should that also be something external?

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

Re: [dmarc-ietf] Meetecho at IETF 108

[Murray S. Kucherawy]

On Tue, Jul 28, 2020 at 9:08 AM Hector Santos  wrote:

> Sorry I missed it.
>
> Is there a video capture?
>

It's standard practice to make the audio stream available afterwards.  I
don't know offhand if they're planning to make the video presentation
available.  I'll find out and report back.

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

Re: [dmarc-ietf] DMARC marketing

[Jesse Thompson]

On 7/22/20 5:55 PM, Jim Fenton wrote:
> These get to the heart of the problem: DMARC policy was designed for
> official mail that is about business transactions. If that was the way
> it is actually used, we wouldn't be having this problem. But it was
> oversold, and it is being used in use cases (like on domains that have
> mailing list users) that were not intended. 

Yes.  The cybersecurity IT community (at least, in Hi-Ed) largely don't know 
much about email's technical nuances.  But they they know that email phishing 
is a problem, and CISOs demand a solution.  They have their information sharing 
communities (ISACs), where email specialists are generally not included, to 
share knowledge and continue grasping for solutions to phishing.  Enter DMARC 
marketing: phishing is a spoofing problem and you're vulnerable unless you 
protect your domain with DMARC.  Cybersecurity IT tend to see things like DMARC 
as a checkbox towards compliance.  Once that box is checked (varying 
definitions) == job complete (email specialists are left to clean up the mess). 
 Since DMARC was ostensibly invented by the email community, there's not much 
room for local email specialists to convey that it's not a complete solution 
for phishing, and may not be worth implementing on domains used by end-users.  
Momentum suggests that it's easier to just join the bandwagon, move for
 ward with DMARC for every domain (to take advantage of the benefits it 
offers), and hope that Intermediaries can find a solution.


> I'm not convinced that this is a problem that has a satisfactory technical 
> solution.

I think there may be technical and non-technical techniques that can be pieced 
together to arrive at a satisfactory solution, depending on the 
individual/evolving circumstances.  What's lacking is clear guidance for 
Intermediaries; both for people who provide software/platforms, and for those 
installing and configuring them.  What is the best avenue for providing 
guidance?

I mean, this isn't just a problem for MLMs.  Office 365 utterly fails at 
mailbox-level forwarding in a DMARC friendly fashion.  Their latest 
announcement to tenant admins suggest that they're more likely to coerce their 
customers' end-users users to stop forwarding via SMTP altogether.  Maybe 
that's the only generic solution for that type of Intermediary (whereby ARC 
might be an alternative solution to forwarding between trusted institutions).  
Is it satisfactory?  Not to end-users who want to forward their email.  

Maybe the conclusion is that SMTP isn't even appropriate for many types of 
forwarding anymore, but rather pull-based OAuth solutions are more sustainable. 
 This solution is increasingly compatible with the mailbox hosting platforms, 
but isn't widely implemented by the receiving end of the equation.  Is there 
any point in recommending something like that as a solution as a way to move 
the industry in that direction?  

Or does something like this just tend to sort itself out?

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

Re: [dmarc-ietf] Meetecho at IETF 108

[Hector Santos]

Sorry I missed it.

Is there a video capture?

On 7/28/2020 10:07 AM, Murray S. Kucherawy wrote:

If any of those of you who participated in today's working group
session via the Meetecho interface have any thoughts, up or down,
about how well that interface did or didn't work for you, we'd love to
hear them.  You can email the list, the chairs, or me with your thoughts.

-MSK, for the first time sporting an Area Director hat in here


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



--
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/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] Meetecho at IETF 108

[Dotzero]

On Tue, Jul 28, 2020 at 10:20 AM Steven M Jones  wrote:

>
> Having to flip back and forth between the chat column and the
> queue/participant column was awkward. Assuming I didn't miss a setting:
> Why can't we have both shown? At least as an option on larger
> screens/windows/devices.
>
> --S.
>

I had Pidgen open for the chat on my laptop so didn't have to flip back and
forth. This might not be a solution for everyone. I agree that it should be
an integral capability.

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

Re: [dmarc-ietf] Separating DMARC alignment validation from DMARC policy

[ned+dmarc]

The MIME document split was, in hindsight, partly successful (separation of
media types registration was a really good thing), partly unsuccessful (part
five should not have been pulled out of part two), and partly a wash (the
cost/benefit of separating parts one and two ended up pretty much equal IMO).

The devil is always in the details. The DMARC alignment validation process
appears free of policy considerations as currently specified, and is thus a
candidate for separation. But are we sure it will remain so, and is the
separation of a relatively small part of the specification worth it?

Ned


I am not a fan of splitting documents only for an abstract sense of
cleanliness.  There needs to be justification of improved documentation
'cleanliness' and/or useful removal of fate-sharing -- if separate fates
are reasonably expected.




DMARC alignment validation is a basic, mechanical process that produces
a yes/no response.  At that level, it's comparable to the nature of a
DKIM validation, except for the From: field domain.



DMARC "policy" is fundamentally different.  It's not that its mechanism
isn't "mechanical" but that its semantics produce more semantic and
operational challenges.




I think that could reasonably make it worth strongly separating them
into two different documents, no matter has small one of the documents
might be.





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] Meetecho at IETF 108

[Alessandro Vesely]

On Tue 28/Jul/2020 16:07:55 +0200 Murray S. Kucherawy wrote:
If any of those of you who participated in today's working group session via 
the Meetecho interface have any thoughts, up or down, about how well that 
interface did or didn't work for you, we'd love to hear them.  You can email 
the list, the chairs, or me with your thoughts.



At mine, the audio was disconnected right after your presentation.  (I couldn't 
hear Bron's comment).  I tried reloading and reconnecting by the spin icon in 
the lower right corner, to no avail.


The status bar in the codimd editor covers the bottom line of text.


Best
Ale
--



















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

Re: [dmarc-ietf] Fwd: New Version Notification for draft-crocker-dmarc-author-01.txt

[Alessandro Vesely]

On Tue 28/Jul/2020 13:09:29 +0200 Dave Crocker wrote:

On 7/28/2020 4:00 AM, Alessandro Vesely wrote:

On Tue 28/Jul/2020 12:37:32 +0200 Dave Crocker wrote:

On 7/28/2020 12:26 AM, Alessandro Vesely wrote:
Receivers can evaluate the Author: domain just like they would do if it 
were the From: domain. 


So you want to define DMARC as applying to both the From: field and the 
Author: field?  That will defeat the benefit intended for the Author: field.


Yes.  In case of conflict, evaluation of Author: has to be omitted.  For 
example, Author: fields containing multiple mailboxes are not considered.


1. I don't understand the details you have in mind that would make this useful.



It is an optional evaluation.  It's easy to do, if you already verified DKIM 
and SPF.  It is not terribly useful, admittedly, except that having two or 
three "pass" makes for a stronger authentication than just the From:.  The 
chief reason for evaluating it is to give feedback to the MLM.




2. Again, this seems to defeat the purpose of having the Author field.



Why?


(OT-BTW, DMARC spec will have to consider From: fields with multiple 
mailboxes, since they're allowed by RFC 5322.  Should Sender:, in such cases, 
have a domain aligned with one of those?)


My understanding is that DMARC does not work for From: fields with multiple 
domain names.  In that regard, that's another change to the From: field that 
DMARC imposes.



I don't think such restriction is acceptable for a Standard Track document 
which should be applicable to all mail.  According to RFC 5322, in such cases 
the Sender: shall be used to disambiguate.  Then we need to distinguish between 
two differing semantics for Sender:, mediator or agent.



As a new field, Author: doesn't wear a reliable-id trophy, hence receivers 
may refrain to apply policy dispositions.  However, the result of the 
evaluation, conveyed through aggregate report, can tell MLMs if rewriting 
From: was necessary.


How, exactly?



Author: and Sender: domains can be included in aggregate reports along with 
the From: one.  The policy_evaluated can also include more items, specifying 
which evaluations pass or fail.


It will probably help for you to supply detailed specification of the changes 
to DMARC's reporting, so people can assess its likely costs and benefits more 
concretely.



How about this example:

  

  pass
  fail


  fail
  fail


  pass
  pass

none

  mailing_list
  Mailinglist via SPF on ietf.org (IETF mailinglist)

  

?


AFAICS, an pass implies one of three reasons:

* MLM added no footer,
* text/plain message signed with l=, or
* DKIM transformation successfully applied.


Best
Ale
--





























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

Re: [dmarc-ietf] Meetecho at IETF 108

[Steven M Jones]

On 7/28/20 7:07 AM, Murray S. Kucherawy wrote:
If any of those of you who participated in today's working group 
session via the Meetecho interface have any thoughts ...  You can 
email the list, the chairs, or me with your thoughts.



Having to flip back and forth between the chat column and the 
queue/participant column was awkward. Assuming I didn't miss a setting: 
Why can't we have both shown? At least as an option on larger 
screens/windows/devices.


--S.


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

[dmarc-ietf] Meetecho at IETF 108

[Murray S. Kucherawy]

If any of those of you who participated in today's working group session
via the Meetecho interface have any thoughts, up or down, about how well
that interface did or didn't work for you, we'd love to hear them.  You can
email the list, the chairs, or me with your thoughts.

-MSK, for the first time sporting an Area Director hat in here
___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

[dmarc-ietf] Separating DMARC alignment validation from DMARC policy

[Dave Crocker]

I am not a fan of splitting documents only for an abstract sense of 
cleanliness.  There needs to be justification of improved documentation 
'cleanliness' and/or useful removal of fate-sharing -- if separate fates 
are reasonably expected.



DMARC alignment validation is a basic, mechanical process that produces 
a yes/no response.  At that level, it's comparable to the nature of a 
DKIM validation, except for the From: field domain.


DMARC "policy" is fundamentally different.  It's not that its mechanism 
isn't "mechanical" but that its semantics produce more semantic and 
operational challenges.



I think that could reasonably make it worth strongly separating them 
into two different documents, no matter has small one of the documents 
might be.




d/
--
Dave Crocker
Brandenburg InternetWorking
bbiw.net

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

Re: [dmarc-ietf] Fwd: New Version Notification for draft-crocker-dmarc-author-01.txt

[Dave Crocker]

On 7/28/2020 4:00 AM, Alessandro Vesely wrote:

On Tue 28/Jul/2020 12:37:32 +0200 Dave Crocker wrote:

On 7/28/2020 12:26 AM, Alessandro Vesely wrote:
Receivers can evaluate the Author: domain just like they would do if 
it were the From: domain. 


So you want to define DMARC as applying to both the From: field and 
the Author: field?  That will defeat the benefit intended for the 
Author: field.


Yes.  In case of conflict, evaluation of Author: has to be omitted.  For 
example, Author: fields containing multiple mailboxes are not considered.


1. I don't understand the details you have in mind that would make this 
useful.


2. Again, this seems to defeat the purpose of having the Author field.



(OT-BTW, DMARC spec will have to consider From: fields with multiple 
mailboxes, since they're allowed by RFC 5322.  Should Sender:, in such 
cases, have a domain aligned with one of those?)


My understanding is that DMARC does not work for From: fields with 
multiple domain names.  In that regard, that's another change to the 
From: field that DMARC imposes.




As a new field, Author: doesn't wear a reliable-id trophy, hence 
receivers may refrain to apply policy dispositions.  However, the 
result of the evaluation, conveyed through aggregate report, can tell 
MLMs if rewriting From: was necessary.


How, exactly?



Author: and Sender: domains can be included in aggregate reports along 
with the From: one.  The policy_evaluated can also include more items, 
specifying which evaluations pass or fail.


It will probably help for you to supply detailed specification of the 
changes to DMARC's reporting, so people can assess its likely costs and 
benefits more concretely.


d/


--
Dave Crocker
Brandenburg InternetWorking
bbiw.net

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

Re: [dmarc-ietf] Fwd: New Version Notification for draft-crocker-dmarc-author-01.txt

[Alessandro Vesely]

On Tue 28/Jul/2020 12:37:32 +0200 Dave Crocker wrote:

On 7/28/2020 12:26 AM, Alessandro Vesely wrote:

On Mon 27/Jul/2020 20:51:54 +0200 Dave Crocker wrote:

On 7/27/2020 11:15 AM, Alessandro Vesely wrote:
If receivers lookup the Author: domain too, they can evaluate 
authentication and alignment also with respect to that domain.



Since there is no authentication or alignment associated with the Author 
field, I don't know how they can be evaluated.



Receivers can evaluate the Author: domain just like they would do if it were 
the From: domain. 


So you want to define DMARC as applying to both the From: field and the Author: 
field?  That will defeat the benefit intended for the Author: field.



Yes.  In case of conflict, evaluation of Author: has to be omitted.  For 
example, Author: fields containing multiple mailboxes are not considered.


(OT-BTW, DMARC spec will have to consider From: fields with multiple mailboxes, 
since they're allowed by RFC 5322.  Should Sender:, in such cases, have a 
domain aligned with one of those?)



As a new field, Author: doesn't wear a reliable-id trophy, hence receivers 
may refrain to apply policy dispositions.  However, the result of the 
evaluation, conveyed through aggregate report, can tell MLMs if rewriting 
From: was necessary.


How, exactly?



Author: and Sender: domains can be included in aggregate reports along with the 
From: one.  The policy_evaluated can also include more items, specifying which 
evaluations pass or fail.



Best
Ale
--





























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

Re: [dmarc-ietf] Fwd: New Version Notification for draft-crocker-dmarc-author-01.txt

[Dave Crocker]

On 7/28/2020 12:26 AM, Alessandro Vesely wrote:

On Mon 27/Jul/2020 20:51:54 +0200 Dave Crocker wrote:

On 7/27/2020 11:15 AM, Alessandro Vesely wrote:
If receivers lookup the Author: domain too, they can evaluate 
authentication and alignment also with respect to that domain.



Since there is no authentication or alignment associated with the 
Author field, I don't know how they can be evaluated.



Receivers can evaluate the Author: domain just like they would do if it 
were the From: domain.  


So you want to define DMARC as applying to both the From: field and the 
Author: field?  That will defeat the benefit intended for the Author: field.



As a new field, Author: doesn't wear a 
reliable-id trophy, hence receivers may refrain to apply policy 
dispositions.  However, the result of the evaluation, conveyed through 
aggregate report, can tell MLMs if rewriting From: was necessary.


How, exactly?


d/

--
Dave Crocker
Brandenburg InternetWorking
bbiw.net

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

Re: [dmarc-ietf] Fwd: New Version Notification for draft-crocker-dmarc-sender-01.txt

[Dave Crocker]

On 7/27/2020 1:12 PM, Joseph Brennan wrote:
Avoiding it by redefining From: to serve the former purpose of Sender: 
and creating a new Author: to serve the former purpose of From: seems 
to me to start us down a long road of new header fields every couple 
of years.
Oh?  This is cast essentially as a fear. Your basis for believing this 
is what?


As for the re-defining of From:, the premise of the Author: proposal is 
that DMARC has already effected that change.



Verifying that the message really is from phisher.example is a useful 
data point. The receiving system can choose to mark it with a warning 
like "you never had mail before from phisher.example".


Mark  it how and for what use? How does that deal with the user-level 
problems caused by From:-field rewriting?



Consider a DMARC DNS tag for the bank to ask the receiving system to 
verify the From, while the end-user system would not use that tag. I 
think this is the distinction that should be made, for mailing lists 
to work but sensitive data to be more protected than end-user mail.


I don't understand what you are suggesting or how it would work usefully.

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

[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] Fwd: New Version Notification for draft-crocker-dmarc-sender-01.txt

[Alessandro Vesely]

On Mon 27/Jul/2020 22:12:17 +0200 Joseph Brennan wrote:

On 7/27/2020 11:14 AM, Alessandro Vesely wrote:


Let's say I have From: real.bank, and Sender: phisher.example. The
above text seems to imply the receiver is looking up
_dmarc.phisher.example.  Correct?




Avoiding it by redefining From: to serve the former purpose of Sender: and
creating a new Author: to serve the former purpose of From: seems to me to
start us down a long road of new header fields every couple of years. They
are just names.



In the pre-DMARC era, we've been mainly using just From:.  Sender: is used by 
Outlook to display "on behalf of" catchphrase, presumably in an attempt to 
support the historic Sender-Id protocol.  Otherwise, Sender: never had 
traction.  DMARC did put an extra accent on From:, thereby projecting the 
community into a /new territory/, to use Dave's words.


Introducing Sender: and Author: can allow to tone down DMARC rules.  They were 
designed presuming that only a few domains, where email is not used for 
personal correspondence, would use the protocol.  For example, messages cannot 
have multiple authors, and cannot be forwarded with modifications.  Somewhat 
Procrustean for day to day messaging.


From: rewriting is an obnoxious hack.  Yet it's the only possibility for MLMs, 
currently.  By (re-)introducing those two header fields, we can bevel DMARC 
rules, paying attention not to pervert the overall shape.  Three identifiers 
allow better tuning than just one.  If we do a good job, it won't be necessary 
to redo it every couple of years...



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

Re: [dmarc-ietf] Fwd: New Version Notification for draft-crocker-dmarc-author-01.txt

[Alessandro Vesely]

On Mon 27/Jul/2020 20:51:54 +0200 Dave Crocker wrote:

On 7/27/2020 11:15 AM, Alessandro Vesely wrote:
If receivers lookup the Author: domain too, they can evaluate authentication 
and alignment also with respect to that domain.



Since there is no authentication or alignment associated with the Author field, 
I don't know how they can be evaluated.



Receivers can evaluate the Author: domain just like they would do if it were 
the From: domain.  As a new field, Author: doesn't wear a reliable-id trophy, 
hence receivers may refrain to apply policy dispositions.  However, the result 
of the evaluation, conveyed through aggregate report, can tell MLMs if 
rewriting From: was necessary.


That's the only kind of strategy I see for limiting From: rewriting horizon.


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