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

[Alessandro Vesely]

On Tue 28/Jul/2020 19:41:34 +0200 John Levine wrote:

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.



You're right.  Outlook was using "on behalf of" even before Marid.[*]  So 
perhaps Sender-ID derived from that usage, rather than the other way around.



Best
Ale
--

[*] https://bugzilla.mozilla.org/show_bug.cgi?id=221054



















___
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 19:08:25 +0200 Dave Crocker wrote:

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 and expect it to be valid.



It'd be enough to state that the "scrutiny and care comparable to that given to 
the From: header field" include evaluating the domain —if unique— against 
validated identifiers.



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.



If the aggregate report format (see below) includes provisions for transmitting 
the result of those evaluations, the circle is closed.






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.



One of the DMARC specs might suggest what dispositions make sense according to 
the evaluations and the various DMARC records found.  A "fail" result on the 
Author: domain should not compromise delivery (unless the domain is the same as 
the one in From:.)


I understand that asking to perform an evaluation for the sole purpose of 
transmitting the result may sound presumptuous.  However, it's not gonna be the 
only change affecting DMARC software, and it is an easy one to code and a 
lightweight one to run, and, if the Author: domain is significant, its results 
can be interesting for the receiver as well as for the sender.



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.



Best
Ale
--






















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