Re: [dmarc-ietf] my forward signer draft, third party authorization, not, was non-mailing list

[Rolf E. Sonneveld]

On 31/08/2020 18:15, John Levine wrote:

In article  
you write:

The draft suggests use of "x=" as a way to limit exposure.  If you do that,
then an attacker would need to be able to generate mail through your signer
with an "!fs=" tag identifying a domain they control, and exploit the
replay before the time in the "x=" tag arrives.  Sure, it's time-limited,
but it only takes seconds for such an attack to succeed, and automation of
such an attack is easy.

The threats I had in mind were more like attacker finds an old message
in an archive with a fs domain that's been abandoned and the attacker
can reregister.  An x= of a few days should prevent that while still
letting normal list traffic work.

As always, as I hope we all remember DMARC alignment doesn't mean not spam,
and you still do all of the stuff you do to sort your mail.  This scheme
depends on the forwarders you authorize being well-behaved.  That's why I
am concerned that senders need to be selective about who they allow to
forward.


Yep. I like the proposal, but for me the only question left is: (how) 
will this scale? I'm not (yet) convinced it will.


/rolf

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

Re: [dmarc-ietf] Call for Adoption: DMARC Use of the RFC5322.Sender Header Field

[Rolf E. Sonneveld]

>> On 17 Aug 2020, at 16:47, Dotzero  wrote:
> 
> 
> 
>>> On Mon, Aug 17, 2020 at 10:37 AM Dave Crocker  wrote:
> On 8/17/2020 7:33 AM, Dotzero wrote:
 DMARC fixes one thing and one thing only, direct domain abuse.
>>> 
>>> It does no such thing.  Domains can still be 'directly' abused in all sorts 
>>> of ways that DMARC does not affect.  
>>> 
>> 
>> Mea Culpa. You are correct that it only does so in the context of SPF and 
>> DKIM validation which protects rfc5322 From field domains and aligned 
>> rfc5321 Mail From domains (SPF).
>> 
>> 
>> A continuing and in my view fundamental problem with discussion in this 
>> space is the lack of careful and precise language when talking about actions 
>> and effects.
>> 
>> 
>> 
>> So...
>> 
>> DMARC fixes abuse of rfc5322.From field domains.  
>> 
>> THAT is the only thing it does.
>> 
> See above.. I was even more specific than you were in terms of what DMARC 
> does. 
>> And it does it at the expense of breaking some legitimate uses.
>> 
> Only when it is used in domains where there are individual user accounts and 
> not (only) transactional mail uses. If I use a hammer (no pun intended) to 
> pound in a screw, it doesn't make it the right tool for the job.
> 
> Michael Hammer (Inaccurately referred to by you as Herr Hammer)

Talking about precise language, Dave, I think you owe Michael an apology ;-)

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

Re: [dmarc-ietf] Resolving issue #9 (clarify conditions under which to sign and what is being asserted)

[Rolf E. Sonneveld]

> https://trac.ietf.org/trac/dmarc/ticket/9

> Per my comment on the ticket, I think that this has now been addressed with 
> the
> updates done in version -13 (primarily the overview in section 1.1:
> https://tools.ietf.org/html/draft-ietf-dmarc-arc-protocol-13#section-1.1 )
> Any objections to closing this issue?

no objection. 

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

Re: [dmarc-ietf] [ietf-smtp] Moving RFC4406 to historic?

[Rolf E. Sonneveld]

> I have now posted
> https://tools.ietf.org/html/draft-andersen-historic-4406-etal-00 for this 
> task.

> Please let me know if that fits the bill.

it does. 

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

Re: [dmarc-ietf] Agenda for IETF 101 DMARC session

[Rolf E. Sonneveld]

On 16-03-18 10:47, Steven M Jones wrote:

On 3/15/18 10:19 AM, Kurt Andersen (b) wrote:
Two more items for discussion (coming from a chat that I had with 
some of the NCSC folks today):


Thanks for sharing their input.



  * Creating a diagnostic report that would have some additional
information (such as sending address) and URLs without going
quite as far as a forensic report - so something between the
aggregate and forensic levels



I'm probably missing something, but -- aren't email addresses usually 
classed as PII in the EU, whether they're sending or receiving at the 
moment? Seems to me it would run afoul of the privacy regs that tend 
to rule out forensic reports in certain jurisdictions...


Maybe there's a batch/aggregate angle vs.  per-message that helps 
avoid that concern? Would time and URLs alone be useful enough to 
warrant the effort and expense?


Well, given the upcoming GDPR legislation and the sanctions that comes 
with it [1], maybe an agenda item 'DMARC reports and privacy' would be a 
good point. Ideally we would like to have someone present with both GDPR 
and DMARC knowledge...


/rolf

[1] https://www.itgovernance.co.uk/dpa-and-gdpr-penalties

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

[dmarc-ietf] Binding Operational Directive 18-01 require agencies to implement STARTTLS, SPF and DMARC

[Rolf E. Sonneveld]

Hi,

See https://cyber.dhs.gov/

DKIM is mentioned but not required, nor any negative side effects that 
the use of DMARC can have. Has anyone from the IETF been consulted for 
this directive?


/rolf

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

Re: [dmarc-ietf] Feedback requested: draft-davids-dmarc-fi-tag

[Rolf E. Sonneveld]

> On 24/11/2016 21:40, Murray S. Kucherawy wrote:

[...]
>> Terry: Would it be helpful at all for a large operator to get signal
>> that this small operator will be easily overwhelmed, or does it really
>> make a difference?
> 
> That's what is is: nothing more than a signal and/or a request? Just
> like the "ri" tag, basically.

Rate limiting on the sender domain side, providing an SMTP 4.x.y response when 
the server is overwhelmed solves this problem in a natural way.

/rolf

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

Re: [dmarc-ietf] Feedback requested: draft-davids-dmarc-fi-tag

[Rolf E. Sonneveld]

Hi, Marco,

> Thank you for taking the time to respond. Allow me to elaborate a little.
> 
> On 24/11/2016 19:34, Rolf E. Sonneveld wrote:
> 
>>  1. it seems to me that, with this proposal, you move the burden of
>> implementing a rate limiting function from the domain owner to the
>> reporting organization.
> 
> True, but it doesn't have to be that much of a burden in practice, as is
> explained in section 5 of the draft:
> 
> "A report generator in this example would typically honour the "fi" tag
> by sending out a report, storing a 'last report sent' timestamp for
> example.com in memory and maintaining it as a 'do not sent' flag for a
> minimum of $interval seconds during which period no consecutive reports
> are to be sent.  After the flag has cleared, a report may again be sent.
> The cycle then repeats."
> 
> Also, please note: intermediate reports are not generated and not
> queued. They only add to the statistics of aggregated "rua" reports.

I'm sorry, missed that one (just scanned (too) quickly through the draft). As 
it's pretty essential to the draft you may want to add one line to the end of 
section 1 on this.

/rolf

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

Re: [dmarc-ietf] Feedback requested: draft-davids-dmarc-fi-tag

[Rolf E. Sonneveld]

Hi, Marco,

On 24-11-16 10:51, Marco Davids (IETF IMAP) wrote:

Dear community,

I hereby request feedback and support for draft-davids-dmarc-fi-tag.

Problem:

Per-message failure reports as requested by the "ruf" tag are a useful
source of information when debugging deployments or in analyzing attacks.

However, under certain circumstances this property can potentially lead
to an undesirably high volume of reports.  Especially when a Domain
Owner's name is spoofed and abused in a large-scale phishing or other
impersonation attack.

RFC7489 offers only a very limited solution to this problem (in section
7.3).

The lack of a mechanism for a Domain Owner to influence the volume of
reports constitutes an obstacle to deployment of the "ruf" tag feature.

Solution:

In draft-davids-dmarc-fi-tag I propose a new DMARC tag, the "fi" tag. It
provides a Domain Owner with a simple way of requesting limitation of
the rate at which such reports are sent.

Please let me know what you think of it. I'm looking forward to a
fruitful discussion on the design choices I made and I also hope for
support of the idea.


two things, after having had a quick look at the draft:

1. it seems to me that, with this proposal, you move the burden of
   implementing a rate limiting function from the domain owner to the
   reporting organization. This seems not right to me, as it's
   primarily in the interest of the sending domain to receive feedback
   via these reports, not the reporting domains interest. For the large
   ESPs this may be no big deal, they may have means to implement such
   a reporting interval without much pain, but for smaller
   organizations this may cause problems (in terms of resources that
   must be allocated for queuing these reports). To exaggerate a bit:
   the attack vector introduced with 'ruf' is now more or less moved
   from the sending to the reporting domain. Furthermore, most modern
   mail systems have rate limiting technology on board, which can be
   deployed by the sending domain to protect against floodings with
   reports (granted, this shifts the burden also in the direction of
   the reporting domain);
2. I wonder why you have chosen a 32-bit integer, when the unit of
   interval is 'second'. On one hand this provides not enough
   granularity, as the shortest interval (apart from zero) is 1 report
   per second, which may cause significant queues on the side of the
   reporting domain. On the other hand, a 32-bit integer means reports
   can be sent up to 136 years after the moment of an DMARC
   authentication failure, which is way too long to be useful. So I'd
   suggest you make the unit milliseconds, to make it better fit for
   its intended use?

Regards,
/rolf


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

Re: [dmarc-ietf] I-D Action: draft-akagiri-dmarc-virtual-verification-00.txt

[Rolf E. Sonneveld]

On 15-03-16 22:06, Franck Martin wrote:




- Original Message -

From: "Terry Zink" 
To: "dmarc" 
Sent: Tuesday, March 15, 2016 1:04:52 PM
Subject: Re: [dmarc-ietf] I-D Action: 
draft-akagiri-dmarc-virtual-verification-00.txt

+1 to virtual DMARC, -1 to the arguments against it.

Office 365 already supports something like this for our customers to cut down
on Business Email Compromise. Maybe 5% of our customers have DMARC records,
yet we treat all inbound email destined to them as having p=quarantine and
then we figure out roughly who is allowed to send email as them even when
(especially when) they don't authenticate. I talk about this here:
http://aka.ms/AntispoofingInOffice365.

We've been doing DMARC lookups on the header.from and stamping the result for
a while now, and if it doesn't publish DMARC but would have passed if it
did, we stamp the result and call it "Best Guess Pass". However, we use
relaxed alignment, not strict. I talk about this here:
http://blogs.msdn.com/b/tzink/archive/2015/05/06/what-is-dmarc-bestguesspass-in-office-365.aspx

Figuring out implicit/virtual DMARC for everyone else is a much bigger body
of water to boil, but is roughly the same problem. As a large receiver we
have overrides for DMARC failures anyway, so implicit/virtual DMARC would
have those same overrides.


Firstly, DMARC is an opt-in protocol for good reason.

I'm saying this tongue-in-cheek, but that "good reason" is "very limited
deployment in practice." If we would have waited for customers to publish
DMARC records we'd be at 6% adoption rate.


In your first phase, p=none, this will have no effect. In your middle
phase,
p=quarantine, this will cause massive loss of wanted email ...  In your
final phase, p=reject, there will continue to be massive loss of wanted
email.

If large email receivers start junking messages because of implicit/virtual
DMARC failures, senders figure it out eventually even without DMARC
reporting. There's more tools in our toolbox than just junking. For example,
we can add visual warnings to the message. We can choose not to
extract/promote content if the header.from doesn't align with the SPF/DKIM
domain (i.e., an airline sends a flight confirmation and that info is not
shown to the user in a rich manner). We can add throttling limits. And so
forth.


Yes, it may not be cool to call it Virtual DMARC, but basically it is applying 
the DMARC logic, to pass information to other layers.

Google has been doing virtual SPF (aka best guess SPF) for a while. The name is 
confusing, and mixing the results of two systems may produce non-comparable 
metrics.

I think the point, is that several of us have been doing this for quite a while 
and this has been useful in our own internal networks, I'm not sure it needs to 
be formalized to the rest of Internet, except may be under informational status 
or under a (B)CP.


the fact that a number of big receivers already deploy similar 
techniques doesn't mean this draft is a good idea:


 * big receivers do have the resources to maintain and extend a rich
   toolbox to 'balance' the results of a DMARC analysis. There are
   however huge numbers of small to medium receivers who do not have
   this tooling and for whom a virtual/best guess DMARC 'mechanism'
   might remove the nuances there can be in the outcome of a spam
   analysis of real world mail;
 * suppose this draft would evolve into a BCP or Informational RFC, who
   will decide when to move from p=none to p=quarantine and from
   p=quarantine to p=reject, and on what criteria would such a decision
   be based?
 * like Kurt already said, associating this with the name of 'DMARC'
   doesn't sound the right thing to do.


/rolf


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

Re: [dmarc-ietf] I-D Action: draft-akagiri-dmarc-virtual-verification-00.txt

[Rolf E. Sonneveld]

>> On Mar 14, 2016, at 11:28 PM, Kouji Okada  wrote:
>> 
>> We have submitted a draft about DMARC default verification
>> for domains not publishing DMARC records.
>> Any comments will be appreciated.
> 
> Summary: If a domain does not opt-in to using DMARC, treat the domain
> as though it had opted-in to using DMARC with "p=none adkim=s aspf=s".
> Once that's deployed, change it to "p=reject adkim=s aspf=s". Possibly
> do "p=quarantine" between the two.
> 
> There are multiple problems with this suggestion.
> 
> Firstly, DMARC is an opt-in protocol for good reason. It's a lot of work to
> clean up all the mail streams for a domain such that all email is 
> authenticated.
> In many cases it is impossible to do so. Those domains that have not done
> so should not publish a DMARC record.
> 
> Requiring DMARC-esque authentication (let alone strict alignment) from domains
> that are not ready to use DMARC will cause a lot of wanted email to be treated
> as
> having failed that test.
> 
> In your first phase, p=none, this will have no effect. The value of using 
> p=none
> in DMARC is so that domains can take advantage of DMARC reporting without
> loss of legitimate email. You have no reporting, so this provides no value.
> 
> In your middle phase, p=quarantine, this will cause massive loss of wanted 
> email
> while
> still providing no feedback to senders.
> 
> In your final phase, p=reject, there will continue to be massive loss of 
> wanted
> email.
> 
> In none of those phases does your draft add any value. If a receiver wants to
> pay attention to
> whether mail is authenticated or not it can already do so, and it can do so 
> much
> more effectively than any approach that requires strict DMARC style alignment.

Well said, +1.

/rolf

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

Re: [dmarc-ietf] Last call for WG comments on "Interoperability Issues Between DMARC and Indirect Email Flows"

[Rolf E. Sonneveld]

Hi, Tim,

on Sep 7th, I sent a short review of -05, see 
https://www.ietf.org/mail-archive/web/dmarc/current/msg02942.html. I didn't see 
any response, the paragraph I suggested to remove (par. 3.2.5) is still present 
in -07. Can anyone comment on the suggestion to move section 3.2.5 to some 
(future) BCP document?

/rolf

- Original Message -
> From: "Tim Draegen" 
> To: "dmarc" 
> Sent: Tuesday, September 29, 2015 4:34:44 PM
> Subject: [dmarc-ietf] Last call for WG comments on "Interoperability Issues 
> Between DMARC and Indirect Email Flows"
> 
> Hi All,
> 
> The editing team deems this draft as ready for last call review.
> Here are the links to the recently posted v07:
> 
> > The IETF datatracker status page for this draft is:
> > https://datatracker.ietf.org/doc/draft-ietf-dmarc-interoperability/
> > 
> > There's also a htmlized version available at:
> > https://tools.ietf.org/html/draft-ietf-dmarc-interoperability-07
> > 
> > A diff from the previous version is available at:
> > https://www.ietf.org/rfcdiff?url2=draft-ietf-dmarc-interoperability-07
> 
> 
> =- Tim
> 
> 
> ___
> 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] I-D Action: draft-ietf-dmarc-interoperability-05.txt

[Rolf E. Sonneveld]

On 18-08-15 04:09, internet-dra...@ietf.org wrote:

A New Internet-Draft is available from the on-line Internet-Drafts directories.
  This draft is a work item of the Domain-based Message Authentication, Reporting 
& Conformance Working Group of the IETF.

 Title   : Interoperability Issues Between DMARC and Indirect 
Email Flows
 Authors : Franck Martin
   Eliot Lear
   Tim Draegen
   Elizabeth Zwicky
   Kurt Andersen
Filename: draft-ietf-dmarc-interoperability-05.txt
Pages   : 22
Date: 2015-08-17

Abstract:
DMARC introduces a mechanism for expressing domain-level policies and
preferences for email message validation, disposition, and reporting.
The DMARC mechanism can encounter interoperability issues when
messages do not flow directly from the author's administrative domain
to the final recipients.  Collectively these email flows are referred
to as indirect email flows.  This document describes interoperability
issues between DMARC and indirect email flows.  Possible methods for
addressing interoperability issues are presented.


I've reviewed version -05 and have only one comment (about text which is 
not new in this version). I think par. 3.2.5 - Boundary Filters should 
be removed from this document. After all, SPF, DKIM and DMARC have 
always been positioned as 'edge' technologies, where (primarily) the 
edge MTA's of both author administrative domain and final recipients 
administrative domain provide authententication, validation and 
disposition. So although all of par. 3.2.5 is true, IMHO it does not 
belong in a document with title 'Interoperability Issues Between DMARC 
and _Indirect_ Email Flows'. As an alternative we could change the scope 
of the entire document, by leaving par. 3.2.5 where it is now, changing 
the title of the document to 'Interoperability Issues when using DMARC' 
and re-think the use of the word 'indirect' throughout the document 
(some 12 places in the text).


It may be better to move section 3.2.5 to some future to be written BCP 
about the use of DMARC (and SPF and DKIM) in general.


/rolf

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

Re: [dmarc-ietf] Looking for degrees of freedom with Intermediaries - Effort and Policy

[Rolf E. Sonneveld]

[...]

 
  We also appear to be OK with imposing delivery timeouts
 that extend
  beyond the basic timeout set described in RFC5321, given
 what it says
  in RFC2852 (from 2000).
 
 Murray,
 
 Rolf has a valid point.  You are advocating email is to
 radically change into an instant messaging scheme.
 
 Are you now suggesting any properly functioning mediator
 must process ALL its messages as they arrive rather than
 permitting moderator approvals or any realistic post
 processing overhead?
 
 Such issues often confronts small servers to produce
 somewhat erratic handling delays.
 
 Conditional authorization expiry is wholly unrelated to
 protocol timeouts.  A message being queued does not normally
 obtain a fresh set of signatures.  If you are going to
 justify short expiry using RFC5321, why ignore Section
 4.5.4.1 and Section 7.1?
 
 It is fairly common for a system to shutdown while being
 patched whenever an active exploit is noticed.  Undelivered
 messages are then queued and retried later.  Unreasonably
 short expiry will once again make DMARC a primary cause for
 message disruption whenever DMARC asserts inappropriate
 handling requests.

Doug rephrased my concern about short expiry times quite well. Of course author 
domains are free to choose what expiry they want, but the question is: is it OK 
to design a(n extension to a) protocol which don't take the existing status quo 
of Internet mail into account?

/rolf

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

Re: [dmarc-ietf] Looking for degrees of freedom with Intermediaries - Effort and Policy

[Rolf E. Sonneveld]

On 05/19/2015 10:58 PM, Steven M Jones wrote:

On 05/19/2015 13:01, Murray S. Kucherawy wrote:
On Tue, May 19, 2015 at 12:00 PM, Terry Zink 
tz...@exchange.microsoft.com mailto:tz...@exchange.microsoft.com 
wrote:


6.What is the proposed t= time limit? Is 30 seconds enough? Too
long? Too little?

I would guess too little, but at this point that's strictly a guess.  
You need to leave enough time for possible network or other 
transmission problems between the signer and the intermediary you're 
trying to accommodate.


I expect you'll ultimately have to leave that up to the signer, no? 


Yep. And with the 'receiver' deciding whether to honour the requested 
expiration.


Traditional practice would set it sometime between hours and days. 


Agreed.

But when somebody gets around to trying to exploit this window, sites 
with quick (re-)delivery to most of their recipients will probably 
want to cut the length of that exposure down...


which effectively kills the SMTP retry strategy concept [1] and hence 
the store-and-forward character of Internet mail, as we know it since 
the late 70's. Please note that SMTP itself has per command timeouts [2] 
which make short t= limits in the order of sub-minutes or some minutes 
unrealistic for some parts of the Internet and for delivery to some 
organizations which now and then have outages of more than a few minutes 
(no monitoring, no staff etc.). Also, note that large mailing lists may 
take some time to expand the address list and deliver the mail to all 
recipients... So when an expiration time is chosen it has to match the 
real world of mail delivery, which is far better than 20 years ago, but 
still isn't perfect...


/rolf

[1] https://tools.ietf.org/html/rfc5321#section-4.5.4.1
[2] https://tools.ietf.org/html/rfc5321#section-4.5.3.2

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

Re: [dmarc-ietf] Looking for degrees of freedom with Intermediaries - Effort and Policy

[Rolf E. Sonneveld]

On 05/19/2015 10:01 PM, Murray S. Kucherawy wrote:
On Tue, May 19, 2015 at 12:00 PM, Terry Zink 
tz...@exchange.microsoft.com mailto:tz...@exchange.microsoft.com 
wrote:


I think we’re making progress here. So, a message would look like
this:


From: joe@authordomain.example
Authentication-Results: spf=pass (sender IP is xx.xx.xx.xx)
smtp.mailfrom=mlm.example;
dkim=fail (invalid body hash) header.d=authordomain.example
dkim=pass (signature was verified) header.d=authordomain.example;

dkim=pass (signature was verified) header.d=mlm.example;
dmarc=pass header.from=authordomain.example (action=none
cd=mlm.example)

DKIM-Signature: v=1; d=authordomain.example; s=selector; ...

DKIM-Signature: v=2; d=authordomain.example; s=selector;
!cd=mlm.example; l=0; t=now+30 seconds

DKIM-Signature: v=1; d=mlm.example; s=foobar; ...

Some questions:

1.This should be resistant to a replay attack 12 hours in the
future because the “t=now+30 seconds” is part of the DKIM
signature for v=2, and if a phisher copy/pastes it and changes
“v=2” to “v=1”, the “t= “ part will be long past. Right?


t= is the timestamp at which the signature is generated, while x= 
is the expiration timestamp. So, you'd do x=t+lifetime where 
lifetime is the number of seconds you want the signature to be valid.


Do we have information about the percentage of implementations (c.q. of 
the installed base of implementations) that honour the t= and x= tags? 
Is that near 100%, 50%, less?


/rolf

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

Re: [dmarc-ietf] Looking for degrees of freedom with Intermediaries - Effort and Policy

[Rolf E. Sonneveld]

On 05/15/2015 10:28 PM, Dave Crocker wrote:

G'day.

In looking for ways to make a DMARC-style function succeed when the
message transits an intermediary, the current approach has mostly been
proposing one or another wholesale solution.  This creates a complex
space for discussion and tends towards some version of deadly embrace.

It might be helpful to consider /basic types/ of changes that are
reasonable/unreasonable for intermediaries, distinct from how they might
fit into an entire solution.

Reasonable vs. unreasonable pertain to at least two axes:

  1. Amount of work

  2. Policy/Principle

Some choices entail too much work or run afoul of basic operational
policies.  Others might entail some work, but not too much, and might
not be considered as significant violations of established policies.

Here be dragons, of course, but let's try to have the discussion anyhow.

Obviously, there will not be unanimity among all intermediaries, for any
proposal.  So the question really is about plausible rough consensus
among a 'substantial' amount of the community.

The first question is:  what are the 'types' of changes that have been
or might be proposed?


Please define 'changes'. Do you mean: changes which solve the 'p=reject' 
problem for mail that is sent via an intermediary? Or just 'any' changes 
that might help us a fraction to come closer to a solution.

This should turn into some sort of taxonomy,
eventually, but for now an undisciplined core dump(*) of choices would
be best.

Examples:

Modifying the rfc5322.From display-name

Modifying the rfc5322.From address

Modifying the footer of the message body (first body-part.)

Modifying the rfc5322.Subject preface

Performing DMARC validation upon receipt

Performing DKIM/SPF validation upon receipt


+ add an Authentication-Results header.



DKIM-signing all outbound mail.


+ include Authentication-Results in the DKIM-signature of the intermediary.



Registering the intermediary with all potential sites posting to it

Registering the intermediary with all potential sites receiving from
it


/rolf

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

Re: [dmarc-ietf] Indirect Mail Flow Solution Utility Analysis

[Rolf E. Sonneveld]

On 04/25/2015 11:50 AM, J. Gomez wrote:

On Thursday, April 16, 2015 4:11 PM [GMT+1=CET], Scott Kitterman wrote:


I will probably regret this, but since people are throwing around
things like Pareto to argue in favor or against specific solution
areas, I thought it might be useful to take a step back and look at
what might make a solution (or set
of solutions) useful to pursue.

For indirect mail flows like mailing lists, there are three actors
involved:

1.  Originator
2.  Mediator
3.  Receiver

For the purposes of this discussion I'll further categorize the
entities involved as big and small (yes, it's way more complex than
that, but I think that's sufficient).

That leads to six combinations: Originator/Big, Originator/Small,
Mediator/Big, Originator/Small, Receiver/Big, and Receiver/Small.

There have been solutions proposed that only require changes for one
of the three above, that require changes at two of the above, and
that require
changes at all three.

Nice framework.

I'd like to note that it is the presence/existance of actor Mediator which 
induces the DMARC compatibility problems with indirect flows.

I.e., if you supress the Mediator, all is fine and dandy. That fact should at 
leat put some pressure on Mediator regarding the searching for a solution, and 
should induce Mediator to acknowledge that he will have to assume certain costs 
for such a solution.

I see Originator already assuming costs: deploying SPF in DNS and keeping it 
current, deploying DKIM records and DKIM-signing outgoing email, deploying 
DMARC records and being vigilant regarding Header-From alignment in his 
outgoing email, etc.

And I see Receiver already assuming costs: setting up systems to check SPF, 
DKIM and DMARC for incoming email, dealing with the support costs of false 
positives and phised users, sending out DMARC reports, etc.

What costs are Mediators currently taking to improve validation/authentication 
of the email system as a whole?


and what benefits do they get in return?

/rolf

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

Re: [dmarc-ietf] Indirect Mail Flow Solution Utility Analysis

[Rolf E. Sonneveld]

On 04/16/2015 08:34 PM, John R Levine wrote:

The most tedious and unhelpful discussions here have implicitly (or
perhaps explicitly) assumed that receiver nontechnical costs don't
matter, then repeatedly pointed out the true but useless fact that
there are single party mediator changes with trivial technical costs.



Useless because it presumes the non-technical costs of those changes are
high?


At least, we need to look at what non-technical costs they push onto 
other parties.


Some changes have insignificant non-techincal costs and are not 
controversial, e.g., adding a List-ID header for the benefit of 
recipients who know how to use it.  Changes that seem similar may have 
quite different costs, e.g., adding a List-ID and removing subject 
tags, forcing recipients to change the way they sort and organize 
their incoming messages.


I (think I) understand what you mean and I sympathize with your 
reasoning. But how are we supposed to compare non-technical costs with 
technical costs? And what would be the formula to make a fair comparison 
between Technical/Non-technical Costs for Big/Small 
Originators/Mediators/Receivers? The concept of technical vs 
non-technical cost at least doubles the six combinations, mentioned by 
Scott.


/rolf

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

Re: [dmarc-ietf] Indirect Mail Flow Solution Utility Analysis

[Rolf E. Sonneveld]

On 04/16/2015 11:20 PM, John Levine wrote:

Rolf kind of said what I'm thinking here: I agree that we need to look at
the costs.  But are we willing, or not willing, to accept costs that are
not zero?

Sure, everything has some cost.  Something I should have made clearer
is the difference between the costs of changes one imposes on one's
self and those forced on third parties, particularly on third parties
that didn't volunteer to accept them.


yes, but the problem with cost imposed on third parties is that it is 
valued different by the one who imposes it on someone else and the one, 
on which is it imposed. And that is due to the fact, like you said 
earlier today:



The whole reason
we're having this discussion is that a few large originators had
nontechnical costs that they decided to push off onto other people.


Now I think Scott is right that we need to make a step back and his 
analysis might help us to know on which solutions we'd best spend most 
of our time. However, having said that, I'm afraid that we're biased by 
our discussions around the 'DMARC/Mailing List problem'. Let's not 
forget the other use cases of draft-ietf-dmarc-interoperability.


I believe a number of the Mediators, described in par. 3.2 of 
https://tools.ietf.org/html/draft-ietf-dmarc-interoperability-01, cannot 
easily be changed. To give an example: recently when I was working for 
company A, I forwarded an invitation I got from company B to one of my 
addresses at ESP C. I just used the Exchange/Outlook forward function at 
company A and discovered that the mail client I used at ESP C showed the 
address of company B, no the address I have with company A. Company A is 
using Exchange/Outlook 2010 and has no plans to upgrade for the next 
couple of years. Should Microsoft update Exchange to support some 
mediator 'change' for DMARC, then this probably won't be 'retrofitted' 
into Exchange 2010. So it may take many years before I can use a version 
that supports DMARC 'mediation'.


Maybe we should assign a higher score/priority to solutions that only 
cover Originator and Receiver, as (in general) the Originator and 
Receiver are primary stakeholders re. the proper transfer and delivery 
of the message.


/rolf


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

Re: [dmarc-ietf] Updated mandatory tag/conditional signature draft

[Rolf E. Sonneveld]

On 04/14/2015 09:15 PM, Murray S. Kucherawy wrote:
On Tue, Apr 14, 2015 at 8:25 AM, Scott Kitterman skl...@kitterman.com 
mailto:skl...@kitterman.com wrote:


I haven't reviewed his in detail, so I've no opinion.  I was
talking about
this proposal.  Not getting fancy with MIME parts would be nice,
so if this
one can work, I already like it better than Murray's, but if we
have to pile
this onto the stack of nice ideas, then that's probably what I'll
look at
next.


The elegance of John's idea is that it's content-agnostic, and is 
apparently backward compatible because v=1 verifiers will not consider 
the weak signature to be valid (unless they're already quite broken). 
There's no need to learn to parse MIME structure in order to produce a 
signature.


I think the concerning part is deciding when to add the weak 
signature.  The simplest thing is to always add it along with an 
@fs= signature, but then you're basically allowing the forwarding 
domain to sign any content it wants and you'll be approving it too, 
implicitly.



Remembering to what great lengths the ietf-dkim group went to make sure 
that every bit of a message was covered by the signature (and with the 
l= discussions in mind) I would really be surprised if adding the @fs= 
for all outbound mail would be an acceptable solution for the problem.


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

Re: [dmarc-ietf] Updated mandatory tag/conditional signature draft

[Rolf E. Sonneveld]

On 04/09/2015 04:51 PM, MH Michael Hammer (5304) wrote:



-Original Message-
From: dmarc [mailto:dmarc-boun...@ietf.org] On Behalf Of Rolf E.
Sonneveld
Sent: Thursday, April 09, 2015 10:17 AM
To: Anne Bennett; dmarc@ietf.org
Subject: Re: [dmarc-ietf] Updated mandatory tag/conditional signature draft

On 04/09/2015 03:24 PM, Anne Bennett wrote:

Hector Santos hsan...@isdg.net writes:


A database is still needed of which domains will have an outbound
mail stream with two signatures.  Some how the list domains will
still need to register with the Yahoos and tell the Yahoos,
Please send us two signatures authorizing out list domain.I
would like to call this a registration problem because thats seems
to be the area of disagreement as a real problem.

I have to agree; if this is the case, to me, it is a show-stopper.
The genius of the DKIM and SPF and DMARC approaches is that they are
DNS-based, and thus completely decentralized.  The idea that lists
would have to register with the e-mail providers of all of their
contributors, or that I as a (very small!) e-mail provider would have
to figure out what is and isn't a list, doesn't scale.

This can be solved by having the owners of mailing lists publish a yet-to-be-
defined DNS record in which they proclaim the presence of a mailing list
within that domain. I'm contemplating to write a draft for this, as more than
one of the  suggested solutions to the mailing list problem might benefit
from this.


How does this solve anything?


At least it could help in discovering what domains potentially houses a 
mailing list. Whether to trust this assertion is something different. I 
can imagine ESPs could combine this information with information they 
already have about mailing lists (Yahoo once claimed there were only 
30,000 of them, so one way or another they already had some list of 
mailing lists?).



What prevents non-owners of mailing lists proclaiming the presence of a mailing list 
within that domain? What prevents malicious individuals setting up a mailing 
list and proclaiming it?


Nothing at all. But the same holds true for registering with the e-mail 
providers. Actually, publishing a DNS record might be seen as a 
submission for registration with the sender. The sending domain still 
determines whether to accept that registration (and use @fs=domain) or not.





Having said that, I don't like the idea of designing all sorts of auxilliary
technologies to solve the problems introduced by DMARC, or better said: if
we'd come up with such helper technologies we should try to address as
many use cases, presented in [1], as possible. If we do not, at the the end of
the day we'll have created a myriad of new technologies, considerably
increased the complexity of the e-mail ecosystem worldwide with a net
result of zero as long as senders still treat p=reject as p=none/quarantine.


You will never avoid local policy - that is reality. As an aside, don't you mean  
as long as VALIDATORS still treat p=reject as p=none/quarantine.


Yes, sorry, you're right: that should be 'validators'.

/rolf

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

Re: [dmarc-ietf] Updated mandatory tag/conditional signature draft

[Rolf E. Sonneveld]

On 04/09/2015 03:24 PM, Anne Bennett wrote:

Hector Santos hsan...@isdg.net writes:


A database is still needed of which domains will have an
outbound mail stream with two signatures.  Some how the list domains
will still need to register with the Yahoos and tell the Yahoos,
Please send us two signatures authorizing out list domain.I
would like to call this a registration problem because thats seems
to be the area of disagreement as a real problem.

I have to agree; if this is the case, to me, it is a
show-stopper.  The genius of the DKIM and SPF and DMARC
approaches is that they are DNS-based, and thus completely
decentralized.  The idea that lists would have to register with
the e-mail providers of all of their contributors, or that I
as a (very small!) e-mail provider would have to figure out
what is and isn't a list, doesn't scale.


This can be solved by having the owners of mailing lists publish a 
yet-to-be-defined DNS record in which they proclaim the presence of a 
mailing list within that domain. I'm contemplating to write a draft for 
this, as more than one of the  suggested solutions to the mailing list 
problem might benefit from this.


Having said that, I don't like the idea of designing all sorts of 
auxilliary technologies to solve the problems introduced by DMARC, or 
better said: if we'd come up with such helper technologies we should try 
to address as many use cases, presented in [1], as possible. If we do 
not, at the the end of the day we'll have created a myriad of new 
technologies, considerably increased the complexity of the e-mail 
ecosystem worldwide with a net result of zero as long as senders still 
treat p=reject as p=none/quarantine.


/rolf

[1] https://tools.ietf.org/id/draft-ietf-dmarc-interoperability-01.txt

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

Re: [dmarc-ietf] Jim Fenton's review of -04

[Rolf E. Sonneveld]

On 12/22/2014 08:02 PM, Scott Kitterman wrote:

On Monday, December 22, 2014 12:40:36 PM Franck Martin wrote:

- Original Message -


From: Scott Kitterman skl...@kitterman.com
To: dmarc@ietf.org
Sent: Monday, December 22, 2014 7:44:04 AM
Subject: Re: [dmarc-ietf] Jim Fenton's review of -04

On Friday, December 19, 2014 01:30:10 PM Murray S. Kucherawy wrote:

Colleagues,

draft-kucherawy-dmarc-base is nearing IESG conflict review, and it's
been
pointed out that a review from back in April has not been properly
attended
to.

Could I get the WG (forgive me, co-chairs!) to comment on this so that I
can see what changes might be appropriate here?  Having this resolved
before the telechat in the first week of January would be truly
delightful.

Note that some amount of this may have already been addressed (it was
about
-04; -08 is current, and at least the ABNF issue Jim raises will be
handled
in -09), so please at least check -08 when considering your responses.

The posting:
http://www.ietf.org/mail-archive/web/dmarc/current/msg00764.html

There was a recent thread on postfix-users about DMARC rejections when
there are DNS errors that caused me to review -08 to see what it says on
the matter.

At the end of section 5.6.2, it says:
Handling of messages for which SPF and/or DKIM evaluation encounters
a DNS error is left to the discretion of the Mail Receiver.  Further
discussion is available in Section 5.6.3.

My reading of 5.6.3 though is that it only discusses DNS errors in the
context
of failing to retrieve the DMARC record.  Any discussion about handling
DNS
errors for SPF/DKIM seems to be missing.

I had a few issues with a large sender, which had their TXT record
overloaded (not uncommon, this is where google analytics and other wants to
prove who you are). Combined with a low TTL, it would happen rarely, but
frequently enough that an SPF could not be assessed and DMARC would fail.
The fallback mechanism in bind is slow when you have edns issues.

1) I wished that SPF record location would have been _spf.domain name
2) may be here the recommendation, is that with DMARC it is best to tempfail
an email if you can’t get an SPF result due to DNS (same with DKIM), rather
than carry on and pass the result to higher policy layers.

The underscore location was considered at the time, but in 2004 we believed
that it would have created a significant barrier to deployment since many
tools/service provider control panels at the time didn't allow it.  It would
certainly be better now, but as with type SPF, there's no transition
mechanism.  If we were going to transition SPF records anywhere, it would have
been better to do it to the new RR type.

Both SPF and DKIM do have a temporary error state, so it's certainly possible
to include this.  I think it's totally up to the receiver if they choose to
defer (45X) or choose not to use DMARC in case of a temporary error in one of
the underlying protocols (i.e. SPF or DKIM) making it impossible to make a
complete DMARC evaluation.

Perhaps 5.6.3 needs something like SHOULD NOT act on DMARC policy if a
temporary error in SPF or DKIM processing prevents a full evaluation.


+1

/rolf

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

Re: [dmarc-ietf] Jim Fenton's review of -04

[Rolf E. Sonneveld]

On 12/22/2014 08:16 PM, Dave Crocker wrote:

On 12/22/2014 11:11 AM, Rolf E. Sonneveld wrote:

Perhaps 5.6.3 needs something like SHOULD NOT act on DMARC policy if a
temporary error in SPF or DKIM processing prevents a full evaluation.

+1


We need to be careful about how this is phrased.  I specifically suspect
that the above suggested wording is a bad idea, or worse, probably wrong.

DMARC /requires/ prior validation of the author From domain via a
lower-level mechanism.  SPF and DKIM are defined for now.  If neither of
them validates the domain, then DMARC fails.


What do you mean with 'validates'?:

a) confirm that the domain exists and that the required information for 
the lower-level mechanism(s) could successfully be determined?

b) 'authenticates'
c) something else?

Assuming you mean a) (or something that is close to it), then the 
problem here is: what if SPF cannot be 'validated' while DKIM can, and 
vice versa?




There is no 'should' about it.  It fails.

Failing means that the polices are not applied.  As in MUST NOT be applied.


This seems to me to be contradictory of the way the word 'fails' is used 
in http://tools.ietf.org/id/draft-kucherawy-dmarc-base-08.txt. For 
example: how should I interpret these last two lines, when comparing 
this with what is being said about 'fails'  in the context of 
'p=quarantine' and 'p=reject':



   quarantine:  The Domain Owner wishes to have email that fails the
  DMARC mechanism check to be treated by Mail Receivers as
  suspicious.  Depending on the capabilities of the Mail
  Receiver, this can mean place into spam folder, scrutinize
  with additional intensity, and/or flag as suspicious.


and


   reject:  The Domain Owner wishes for Mail Receivers to reject
  email that fails the DMARC mechanism check.  Rejection SHOULD
  occur during the SMTP transaction.  See Section 9.3 for some
  discussion of SMTP rejection methods and their implications.


Please read http://tools.ietf.org/id/draft-kucherawy-dmarc-base-08.txt 
again and mark every occurrence of he word 'fail' or 'fails'. Often it 
is used in the context of DKIM and SPF checks, sometimes in the context 
of DMARC mechanisms etc.


I'm confused.

/rolf

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

Re: [dmarc-ietf] draft-kucherawy-dmarc-base updated (-06)

[Rolf E. Sonneveld]

Hi, Murray,

On 11/11/2014 02:52 AM, Murray S. Kucherawy wrote:
I've posted an update to the base draft, based on recent feedback from 
Ned and others.  Hopefully I've resolved all of the concerns 
(especially the major ones), as the ISE would like to send the draft 
to the IESG for conflict review in the next day or two.  It also has 
to begin formal review of its IANA Considerations section as soon as 
possible.


Thanks to all who provided recent comments to lead us to this version.


I started earlier this week a review of -05. Please find below my 
comments, I think most if not all of them also apply to -06. I didn't 
have time to finish my review, but thought to send my comments 'as is' 
(before -07 is published ;-)). Most of my comments are of type 
'editorial nits', no big changes proposed ;-)


Regards,
/rolf

Abstract:

   This lack of cohesion has several effects: receivers have difficulty
   providing feedback to senders about authentication, senders
   therefore have difficulty evaluating their authentication
   deployments, and as a result neither is able to make effective use
   of existing authentication technology.


This focuses on the reporting function of DMARC, leaving out the policy 
part of it.


Suggested text:

   This lack of cohesion has several effects: senders have difficulty
   providing information about their use of an authentication policy
   and receivers have difficulty determining a disposition preferred by
   senders. Vice versa, mail receivers have difficulty providing
   feedback to senders about authentication, senders therefore have
   difficulty evaluating their authentication deployments, and as a
   result neither is able to make effective use of existing
   authentication technology.

Introduction:

   [...] mail receivers have tried to protect senders [...]


Suggested:

   [...] mail receivers have tried to protect senders and their own
   users/customers [...]


Starting with DMARC allows domain owners and receivers to collaborate 
by, the terms 'domain owners', 'receivers', 'senders' and 'SMTP 
receivers', 'Mail Receivers', 'mail receivers' are used throughout the 
document. I'd suggest to add a definition of the term ' Mail Senders' to 
the introduction part of chapter 3 and then use only the terms as 
defined in 3., throughout the document. Suggested text for the term Mail 
Sender:


 * Mail Sender: the sender of mail with a domain for which the Domain
   Owner may have published a DKIM public key and/or an SPF
   authentication record and/or a DMARC policy;


(although we may want to not mention DKIM or SPF here).

2.2 Out of Scope

Add:

ocousin domain attacks

3.1.2 Key Concepts

Last sentence: add a reference to this 'other referenced material'.

3.1.3 Flow diagram

The box titled 'User Mailbox' could give the impression that there's 
only one choice for delivery. However, quarantining can be done without 
delivery to a mailbox. I'd suggest to label this box 'rMDA'.


The part within parentheses of step 6:

 6. Recipient transport service conducts SPF and DKIM authentication 
checks by passing the necessary data to their respective modules, each 
of which require queries to the Author Domain’s DNS data (when 
identifiers are aligned; see below).


might indicate that SPF and DKIM authentication checks need not be 
performed when identifiers are not aligned. However, for sake of 
reporting, SPF and DKIM authentication checks will in general always be 
done, or am I missing something?


3.1.4.1 DKIM-authenticated Identifiers

remove (or change) the 'Cousin Domain' example: it doesn't hold when a 
bad actor is signing the mail with d=cousindomain and 
RFC5322.From=localpart@cousindomain


4 Use of RFC5322.From

Last bullet (The DMARC mechanism ...). It seems the other bullets 
provide reasons why RFC5322.From is chosen while the last one does not. 
It looks to me as a circular reasoning.


5.2 DMARC URIs

It is not clear from the text what the report originator must do when 
the report payload exceeds the maximum size as indicated by the record. 
Should it not send anything, should it split up reports, should it 
notify the requester that there was a report exceeding the maximum size?


5.3 General Record Format

adkim and aspf do not provide a list of all possible options (like is 
done for fo and p). Of course it is pretty obvious that for 'strict' the 
's' must be used, but it's not clear from the text.


Suggested edit:

   adkim: (plain-text; OPTIONAL, default is r.) Indicates whether
   strict or relaxed DKIM identifier alignment mode is required by the
   Domain Owner.

   Possible values:

   r: relaxed DKIM identifier alignment mode required
   s: strict DKIM identifier alignment mode required

   See Section 3.1.4.1 for details.

and

   aspf: (plain-text; OPTIONAL, default is r.) Indicates whether
   strict or relaxed SPF identifier alignment mode is required by the
   Domain Owner.

   Possible values:

   r: relaxed SPF identifier 

Re: [dmarc-ietf] draft-kucherawy-dmarc-base feedback

[Rolf E. Sonneveld]

On 11/09/2014 04:03 PM, Tim Draegen wrote:

On Nov 8, 2014, at 8:38 PM, Franck Martin fra...@peachymango.org wrote:

There are no secret sauces. I thought it was clear this type of language on 
this list is frown upon as non constructive?

Just a point of clarification here.  The original author was referring to decisions that 
receivers make when processing email.  Secret sauce is often shorthand for 
the local conditions that exist at a receiver (eg input from local user behavior, site 
specific content scanning, etc).

No foul here.  Play on!


thanks, Tim.

Frank, this was exactly the meaning of 'secret sauce' I had in mind, 
like it has been used in the past, see for example [1] and [2]. From [2]:


   Obviously, in computing reputations via traffic analysis, some
   private algorithms may come into play.  For some RSPs, such secret
   sauce comprises their competitive advantage over others in the same
   space.


Although this is said in the context of reputation, a similar meaning 
can apply to the internal decision making process within MBP's/ESP's 
when dealing with the results of e.g. SPF verification or DMARC 
verification.


Having said that, it's still interesting to learn (if you want to share 
that) what LinkedIn does in situations where there are e.g. multiple 
addresses in a From field.


/rolf


[1] http://lists.opendkim.org/archive/opendkim/users/2011/06/1143.html
[2] https://tools.ietf.org/html/draft-ietf-repute-considerations-03

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

Re: [dmarc-ietf] draft-kucherawy-dmarc-base feedback

[Rolf E. Sonneveld]

On 11/08/2014 01:40 AM, J. Trent Adams wrote:

[...]


5.6.2.  Determine Handling Policy

To arrive at a policy disposition for an individual message, Mail
Receivers MUST perform the following actions or their semantic
equivalents.  Steps 2-4 MAY be done in parallel, whereas steps 5 and 6
require input from previous steps.  In the case where multiple
identifiers were extracted from the RFC5322.From field, steps 1-4 are
performed for each identifier, collecting the results, prior to
performing steps 5 and 6.

The steps are as follows:

1.  Extract the identifier(s) from the addr-spec portion of the
RFC5322.From field of from the message (as above).

2.  For each identifier, query the DNS for a DMARC policy record
published by the Domain Owner(s). Continue if at least one
policy record is found, or abort DMARC evaluation otherwise.
If there is more than one identifier, the DMARC policy found
for each identifier SHOULD be collected as a set to be used in
step 5. See Section 5.6.3 for the details of policy discovery.

3.  Perform DKIM signature verification checks.  A single email may
contain multiple DKIM signatures.  The results of this step are
passed to the remainder of the algorithm and MUST include the
value of the d= tag from all checked DKIM signatures.

4.  Perform SPF validation checks.  The results of this step are
passed to the remainder of the algorithm and MUST include the
domain name used to complete the SPF check.

5.  Conduct identifier alignment checks.  With authentication checks
and policy discovery performed, the Mail Receiver checks if
Authenticated Identifiers fall into alignment as described in
Section 3.  If one or more of the Authenticated Identifiers align
with an identifier extracted from the addr-spec of the
RFC5322.From domain, the message is considered to pass the
DMARC mechanism check.  All other conditions (authentication
failures, identifier mismatches) are considered to be DMARC
mechanism check failures.

6.  Apply policy.  Within the set of DMARC policies found in Step
2, select the most strict (with p=none being the least strict,
next being quarantine, and reject being the most strict) to
use in applying policy.  See Section 5.3 for details of the
discovered DMARC policies.


We would like to apply the most strict policy, but doesn't that conflict 
with the p=none policy, where Domain Owners can start gathering reports 
without having to bother about impact on the disposition of their mail? 
Furthermore, doesn't a 'most strict' conflict with the meaning of the 
pct tag:



The purpose of
the pct tag is to allow Domain Owners to enact a slow rollout
enforcement of the DMARC mechanism. The prospect of all or
nothing is recognized as preventing many organizations from
experimenting with strong authentication-based mechanisms.


Treating the mail with the most strict policy for a From field with two 
addresses, where one of them has p=reject and the other p=none, may have 
the result that p=reject is applied for mail from the domain which has 
policy=none. Or am I missing something?


/rolf

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

Re: [dmarc-ietf] draft-kucherawy-dmarc-base feedback

[Rolf E. Sonneveld]

On 11/08/2014 09:20 PM, Brett McDowell wrote:
I support making no change in dmarc-base-05 that might change how 
current mailbox providers implement dmarc-base.  But to the extent 
this collection of contributors would like to see the 
recommendations/requirements in section 5.6.1 updated to better 
harmonize with related RFC's, I support Trent's proposal as it seems 
to introduce the least amount of increased risk to fraud.


That said, we do have people here familiar with large-scale mailbox 
provider deployments (Google, Yahoo!, Hotmail, etc.). I'd like to ask 
them if they expect Trent's changes to have any impact on how they 
implement dmarc-base today.  If it will, I think we should consider 
these changes for a future version of dmarc-base and let this version 
go through with these requirements unchanged.  As you all know, there 
are now years of experience deploying dmarc-base with these 
requirements as written.  Those deployments have had tremendous 
success protecting users from domain-spoofing the RFC5322.From field.


The importance of the current dmarc-base specification's efficacy at 
blocking domain-spoofed phishing attacks should not be 
underestimated.  I advise extreme caution when considering any 
normative changes at the 11th hour.


Dear high volume MBP's, will any of these changes in Trent's proposal 
alter how you implement dmarc-base today?


The current effort to publish DMARC as informational RFC is mainly, to 
document the current specification 'as is', to be able to refer from 
other documents to a published spec. The concerns raised by Ned and the 
proposal of Trent try to address situations, where the spec does not yet 
describe what to do (RFC5322.From with multiple addresses), or leaves 
room for different interpretations/implementations. As such I welcome 
the text proposed by Trent. If the big MBP's deviate from what that text 
describes, then in my opinion:


 * either this is part of the 'secret sauce' which is being applied by
   Mail Receivers anyway (no matter what a spec will prescribe)
 * or (better) the big MBP's will need to come up with text describing
   what their implementations will do in these specific cases.


Not changing the text, because the MBP's might have implemented these 
cases in a different way than what is being proposed here, but not 
documenting that way, is not a good idea, IMHO.


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

Re: [dmarc-ietf] Indirect mail flows: DKIM signature breakage by cloud anti-virus/spam provider

[Rolf E. Sonneveld]

All,

On 09/15/2014 07:39 PM, Henrik Schack wrote:
In Denmark we have a somewhat large (10K+ domains) anti-virus/spam 
provider breaking DKIM signatures.
They break DKIM signatures on incoming email by adding a Virus 
scanned by  line to the body of the email.


Not sure how to fix this, but perhaps some day they'll get tired of my 
bi-monthly calls and emails complaining about how they do things.


it's nice to see how many respondents in this thread gave all sorts of 
advise to Henrik how to deal with a problem, which basically cannot 
solved by him because it is caused by some 3rd party (modifying the body 
of a mail for adv. purposes).


I interpreted Henrik's mail as a followup to the thread that John Kelly 
started, titled 'Indirect mail flows'. In my view both John and Henrik 
tried to make (a start of) an inventory of all sorts of real-life 
situations that potentially can break DKIM signatures or more in 
general: cause DMARC failures for legitimate mail flows where sending 
DMARC policy is p=reject.


And before starting the discussion about possible solutions it may be 
better to first 'complete' [1] this inventory.


/rolf

[1] the inventory will never be 100% complete, of course.

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

Re: [dmarc-ietf] Support for DMARC p=reject

[Rolf E. Sonneveld]

Hi, Doug,

On 05/22/2014 10:21 PM, Douglas Otis wrote:

Dear Brandon,
See comments inline:

On May 12, 2014, at 12:30 PM, Brandon Long bl...@google.com 
mailto:bl...@google.com wrote:


On Mon, May 12, 2014 at 12:16 PM, Douglas Otis doug.mtv...@gmail.com 
mailto:doug.mtv...@gmail.com wrote:



On May 11, 2014, at 12:47 PM, Gabriel Iovino
giov...@people.ops-trust.net
mailto:giov...@people.ops-trust.net wrote:

 Greetings,

 Last week I was having a conversation with a familiar person on
this
 mailing list and I was expressing my disappointment with the
 negativity towards Yahoo[1] and AOL[2] for breaking email. I was
 encouraged to share these thoughts on this list.

 I believe email is already broken[3][4][5][6] and DMARC p=reject
 moves us towards a position where email is less broken. Will
there
 be some bumps[7] along the road? Sure but a few bumps are no
reason to
 leave email in it's current state.

 I applaud Yahoo and AOL for taking the first few punches and I look
 forward to the day when Google and Microsoft follow their lead.

 Thank you for all the hard work you have done to improve the
state of
 email!

 Gabriel Iovino

Dear Gabriel,

While email is generally abused, DMARC's intent was to better
protect transactional email which Yahoo may put in jeopardy.
 There will be a forthcoming draft to allow Author-Domains a
means to request restrictive policies against normal user email
accounts without disrupting very legitimate communications.  The
draft places the burden of mitigating disruption on those making
the requests.  Otherwise, it won't be too much longer before even
DMARC is ignored when misapplied against user accounts.


Where can we learn more about this?


An update is pending recovery of xml.resource.org/public/rfc/bibxml/ 
http://xml.resource.org/public/rfc/bibxml/. You don't miss it until 
it is gone. :^(  I should have been more proactive about transferring 
reference content.



Yahoo has suffered from a lack of security permitting millions of
their users accounts to be compromised.  A better approach would
not use DMARC, but would federate third-party services they can
see their customers employ.  The federation of email, much like
that of XMPP, would be an effective means to exclude bad actors
without breaking mailing-list and other third-party email
services.  As it is now, it seems Yahoo only protects their own
mailing-list operations which really does not warrant a basis for
applauding such efforts.


I feel that there is a theory that has gone around as to why AOL and 
Yahoo! have done this, but I don't know as there has been any proof 
of that or acknowledgement.  For one, the level of hijacking we see, 
and the level of spam I personally receive that has at least a From 
name of someone I know, lead me to question that theory.


I have notified several friends that their accounts were compromised. 
 Most did not like having to change their password.


Also, unless you know otherwise, my understanding was that Yahoo 
Groups didn't have any mitigation of DMARC policies until recently, 
and they implemented the same (and only currently useful) mitigation 
of re-writing the From header, and did so well after yahoo.com 
http://yahoo.com/ went to REJECT.


Rewriting the From header field in itself is disruptive.  This 
prevents review of prior conversations from an individual.  Often you 
might remember who said something without recalling some of the details.



Also... federation across millions of servers?  That seems... unlikely.


Federation simply means sending servers authenticate their domain and 
allow receivers to decide whether they wish to disallow messaging from 
unknown domains.  That feature is sorely missing from SMTP.  In this 
case, it only comes into play for third-party servers used by users of 
the Author-Domain asserting a DMARC policy request.  The scale of this 
is likely to be in the area of about 30K.


This number of 30K has been first mentioned by Yahoo! and after that it 
has been mentioned a couple of times by various people, but I have yet 
to see any proof that this figure is correct. Apart from this, quoting 
your own mail, you mention [...] tens of thousands of legitimate 
services that might be sending on behalf of their client [...]. 
Although I think TPA may have its use for specific author/sender 
combinations [1], it definitely is not the answer to the current 
problems, introduced by Yahoo! and AOL, when they activated 'p=reject'. 
It simply will not scale enough and it remains to be seen that the 
too-big-to-ignore ESPs will spend time and money on the use of TPA, as 
they have their own mailing-list-like fora, which provide them revenues. 
Not to mention the privacy aspects of TPA...


/rolf

[1] My company DKIM-signs mail on behalf of some customers, a proper TPA 

Re: [dmarc-ietf] Support for DMARC p=reject

[Rolf E. Sonneveld]

Hi, Doug,

On 05/22/2014 11:56 PM, Douglas Otis wrote:

[...]



This number of 30K has been first mentioned by Yahoo! and after that 
it has been mentioned a couple of times by various people, but I have 
yet to see any proof that this figure is correct. Apart from this, 
quoting your own mail, you mention [...] tens of thousands of 
legitimate services that might be sending on behalf of their client 
[...]. Although I think TPA may have its use for specific 
author/sender combinations [1], it definitely is not the answer to 
the current problems, introduced by Yahoo! and AOL, when they 
activated 'p=reject'. It simply will not scale enough and it remains 
to be seen that the too-big-to-ignore ESPs will spend time and money 
on the use of TPA, as they have their own mailing-list-like fora, 
which provide them revenues. Not to mention the privacy aspects of TPA...


Dear Rolf,

I strongly disagree with the assumption TPA does not scale to levels 
needed by AOL or Yahoo. Not having TPA declare the exceptions needed, 
both receiving and then offering feedback will likely to involve 
greater levels of network resources.  TPA is structured to ensure it 
can be supported by a single DNS transaction.  This allows for 
effective caching so perhaps only one out of 10 queries sees an 
authoritative response.  Can that be said for any other email protocol?


I'm not talking about that type of scaling. What I mean is, that it will 
take a massive amount of work to gather the right information about who 
is subscribed where to what list, to update this information on a 
continuous basis and to get this (changing information) in DNS. But 
maybe I misunderstand what will be in the draft, I'd better wait for the 
draft.


/rolf

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

Re: [dmarc-ietf] SRS helps SPF/DMARC

[Rolf E. Sonneveld]

On 02/15/2014 09:45 AM, Vlatko Salaj wrote:

On Saturday, February 15, 2014 2:42 AM, Murray S. Kucherawy 
superu...@gmail.com wrote:



maybe spec should have a note about incompatibility with ATPS. but that's it.

...but they aren't incompatible.

i only skimmed ATPS specs, so maybe i misunderstood something. however, as far
as i see it, the way it's defined is incompatible with DMARC.

ATPS changes d= tag to 3rd party, while from: header remains 1st party.
essentially, this breaks DKIM alignment, in DMARC terms. the only way ATPS
could be compatible is as a DMARC policy override, similarly to the way
ATPS defines compatibility with ADSP.

so, mutually exclusive. imo, since ATPS standard is still in its making,
it should be changed to account for DMARC.


One can argue whether it is correct to require to change ATPS, which has 
(Expirimental) RFC status, to accomodate for DMARC, which has no IETF 
status yet.



  however, i'm not sure if that's
possible, without making significant changes to DKIM as well.

or just use it as a policy override.



Anyone receiving large amounts of mail and generating reports based on them
(Yahoo, for example) has enough data to tell you what percentage of DKIM
signatures are passing, and what percentage of those are DMARC-aligned.


Not sure why you (Murray) mention Yahoo here, but in general it would 
help us when the major ESPs would share their statistics on things like 
DMARC alignment, SPF pass/fail rate, DKIM pass/fail rate, DKIM+SPF 
fail/fail rate etc. The most interesting question here being: what 
percentage of legitimate mail fails both SPF and DKIM (DMARC).



reports i'm dealing with go around 10%. however, my pool is too small to
be considered deal-breaking. however, in my experience, DMARC alignment
is a b*atch.



SPF (the document, not so much the protocol) was just revised to change
its status from Experimental to Proposed Standard. SRS didn't come up
there either; the consensus supported a version that continued not to deal
with forwarding directly.

i guess that answers a question i woke up today with: would any major
mailbox provider be interested into adding SRS into their forwarding
logic? considering how they look at SPF as annoyance as it is [yahoo
not publishing any SPF records, for example], no wonder they don't
like making that protocol even more hard to deploy.


Forget about SRS. To paraphrase John Levines statement about the budget 
that receivers have to fix the problems of the sender:


The total budget at all _forwarders_ for solving senders' problems is $0.

For senders and receivers there can be (some) mutual interest in solving 
problems at either side (this is true for 'transactional' mail), but 
there is no mutual interest between senders and forwarders and there's 
no mutual interest between forwarders and receivers.


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

Re: [dmarc-ietf] DMARC implementation Question

[Rolf E. Sonneveld]

On 01/28/2014 12:45 AM, Franck Martin wrote:


*From: *Rolf E. Sonneveld r.e.sonnev...@sonnection.nl

*To: *George Moje george.m...@computershare.com,
dmarc@ietf.org dmarc@ietf.org
*Sent: *Monday, January 27, 2014 3:04:13 PM
*Subject: *Re: [dmarc-ietf] DMARC implementation Question

On 01/24/2014 02:18 PM, George Moje wrote:

Currently we are using SPF records but no DKIM.  Can we
implement DMARC with just SPF records?


according to par. 3.1.3 of the DMARC spec
(https://datatracker.ietf.org/doc/draft-kucherawy-dmarc-base)
DMARC assumes an author to setup and apply DKIM signing.

Apart from that: be very careful when using only SPF in
combination with DMARC: please take into account that for DMARC
there's no difference between an SPF -all, ~all and ?all
situation. None of them provide a 'pass' for DMARC, if I read the
spec correctly.

No,

If the policy is p=none, DMARC should not override the SPF policy 
(especially for -all), DMARC with p=none, does not change the way the 
email is treated in regards of SPF or ADSP. If p!=none then DMARC 
tells the receiver to not action on the SPF policy and tell the 
receiver to ignore ADSP, as DMARC will now tell how to handle the email.


Please re-read my message. I didn't mentioned a 'DMARC pass', I 
mentioned the result of SPF as input to the DMARC decision process. In 
that regard, neither SPF -all, nor ~all nor ?all give an 'SPF pass' 
input to DMARC. In addition to that, if the DNS lookup for the SPF 
record fails, it's up to the receiver to decide to give a tmpfail or a 
permanent fail. That was the reason I said: be careful when applying the 
combination SPF + DMARC without DKIM, as it may result in rejection of 
valid mail (in case p!=none).




However, regardless of the DMARC p=, DMARC takes the result of the SPF 
test (pass, soffail, fail,...) and if there is a pass, compare the 
domain used by SPF for its pass with the domain in the From:. If there 
is alignment then you have a DMARC pass. You don't need DKIM to have a 
DMARC pass.


you need to do SPF and DKIM on all your emails for p!=none, because in 
some cases SPF is more suitable than DKIM and vice versa, so you want 
the benefit of both.


Right.

/rolf

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

Re: [dmarc-ietf] Open DMARC discussion meeting: Monday 2013-10-20 0830-0930 UTC-0400

[Rolf E. Sonneveld]

Kurt,

On 10/29/2013 10:14 PM, Kurt Andersen wrote:
It would be good to get Mike Hammer, Franck Martin and Mike Jone's 
take on the discussion too. I did not take notes per se but the room 
was pretty packed with attendees. The general take-away is that people 
are interested, but feel like the steps to get started (beyond 
publishing the DNS record -- more along the lines of what do I do with 
the reports I get back) are still unclear.


I would say that the attendees in the room probably represent the next 
segment in the adoption curve beyond the early adopters group. They 
are looking for a bit more of a turn-key approach or are looking for 
the value equation to implement for either smaller receivers and 
senders or enterprise deployments (which are frequently both senders 
and receivers).


One topic that received some discussion was around the best way to 
deal with third-parties and DMARC -- how to do it, etc.


Mike, Mike, Franck -- care to chime in with any other thoughts?


is there an audio/video/jabber/meetecho/whatever recording of the 
meeting available?


/rolf

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