Re: [dmarc-ietf] Info - DMARC at WEB.DE, GMX, mail.com coming soon

[Tim Draegen]

On Mar 9, 2021, at 11:38 AM, Arne Allisat  wrote:
> 
>  Just a short info to whom it might interest:
> 
> Very soon, we will go live with DMARC check on incoming mails for all 
> mailboxes operated by WEB.DE, GMX & mail.com.
> That covers several hundreds of recipient domains [1] and roughly 50% of the 
> German email users.
> 
> For now we will handle reject and quarantine policies equally as quarantine. 
> GDPR compliant, aggregated DMARC reports will follow as well (without giving 
> an ETA).


Congratulations! That is a big milestone.

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

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

[Tim Draegen]

> On Aug 20, 2020, at 2:16 PM, Murray S. Kucherawy  wrote:
> 
> On Thu, Aug 20, 2020 at 1:59 AM Alessandro Vesely  > wrote:
> I am wondering whether companies like Dmarcian could implement third-pary 
> whitelisting.  As they receive and analyze DMARC aggregate reports on behalf 
> of many mail sites, they probably are able to distinguish various level of 
> authentication failures, from mailing lists to misaligned ESPs, to actual 
> abusers.  In that case, they could maintain a whitelist tailored for any 
> given client.  The client would set, say:
> 
> _dmarc.client.domain.example IN TXT "v=DMARC1; 
> rua=mailto:client...@ag.dmarcian.com ; 
> snd=client-id.rhswl.dmarcian.com ; 
> [...]"
> [...]
> 
> Having spent a lot of time and energy building a DKIM-based reputation system 
> that (IMHO) showed promise, I made it available for people to try for free.  
> There was no uptake, even after presenting its promising results in places 
> like M3AAWG.  Times may have changed, but in retrospect I think there are too 
> many "what-ifs" for add-ons of this nature to be seen as feasible.  The 
> issues seem to be:

Hi MSK, hi Ale,
I can second that MSK's DKIM-based reputation system is amazing. From where I 
sit, it's like a flying saucer that humans just haven't figured out how to fuel 
quite yet. I believe that fuel comes from widespread adoption of domain-based 
email authentication aka DMARC. The challenge of getting the email universe to 
embrace something like DMARC feels at times impossible, but the fact is it just 
takes a lot of coordination, dedication, and consistent levels of exercise to 
stay sane.

That said, Ale, I like the idea of a Domain Owner being able to share some sort 
of exception list for email flows that are recognized by the Domain Owner, but 
are still (for various reasons) beyond the ability of the Domain Owner to 
address. Something like, "I've got a vendor that will never send 
DMARC-compliant email on my behalf". It appeals to my fondness to be able to 
Just Fix Things without having to bother anyone. I don't think it would work, 
though, because it relies on email receivers having to widely implement new 
stuff, and it relies on Domain Owners accurately maintaining another thing. 
It's easier and more effective to get the vendor to do the right thing.

Oh, on 2nd read (I've been consumed with the non-IETF world for a few months 
and only took this up because Ale emailed me at work).. I think keying off of 
"Sender:" is a really bad idea. Multiple policy keys into a single piece of 
email has never made sense.

Third party authorization makes sense to me in theory as a tool for a very 
specific problem. In practice, people and organizations struggle to get first 
party authorization into place. Once they start to tackle their own first party 
authorization, the need for third party authorization tends to evaporate. 
What's left over? People that want to put together a list of authorized third 
parties but aren't quite ready to do their own first party auth?

From a receiver's perspective, it then looks like the first party has no idea 
what it is doing (which is the default anti-spam stance for all Internet mail), 
so then the receiver is now looking at a bunch of factors unrelated to 
first-party auth.. including any third party authorization. EG, the receiver 
notes that the email is authorized by a third-party - a newsletter company. 
"First party" authorization is NOT established, so the receiver has to process 
the email based on the strength of the newsletter company's reputation (among 
other things). So then why bother at all with the construct of "third party 
authorization"?

So I guess put me in the camp of not seeing utility in third party 
authorizations. Better to make the work that needs to be done as clear and as 
simple as possible.

=- Tim

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

Re: [dmarc-ietf] I-D Action: draft-ietf-dmarc-psd-04.txt

[Tim Draegen]

> On May 27, 2019, at 6:59 PM, Scott Kitterman  wrote:
> 
> On Monday, May 27, 2019 6:53:17 PM EDT 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 WG of the IETF.
>> 
>>Title   : DMARC (Domain-based Message Authentication,
>> Reporting, and Conformance) Extension For PSDs (Public Suffix Domains)
>> Author  : Scott Kitterman
>>  Filename: draft-ietf-dmarc-psd-04.txt
>>  Pages   : 11
>>  Date: 2019-05-27
> 
> There isn't much to this update.  It corrects one typo and reverts the RUF 
> MUST NOT as discussed on the list.  As far as I'm aware there are no other 
> pending issues in the WG with the draft.

Hi Scott, I've reviewed the doc and have made some comments. Feel free to 
dispose of them as you will.

I had a hard time with the introduction. "sets of domains within a single 
organization" and "lower level policy" left me not knowing what I was reading. 
I'm unhappy just complaining, so I took a stab at this admittedly difficult 
section. The original:

   DMARC [RFC7489] provides a mechanism for publishing organizational
   policy information to email receivers.  DMARC [RFC7489] allows policy
   to be specified for both individual domains and sets of domains
   within a single organization.  For domains above the organizational
   level in the DNS tree, policy can only be published for the exact
   domain.  There is no method available to such domains to express
   lower level policy or receive feedback reporting for sets of domains.
   This prevents policy application to non-existent domains and
   identification of domain abuse in email, which can be important for
   brand and consumer protection.

My stab:

   DMARC [RFC7489] provides a mechanism for publishing organizational
   policy information to email receivers.  DMARC [RFC7489] allows policy
   to be specified for both individual domains and for organizational
   domains and their sub-domains
   within a single organization.  For TLDs and domains that exist between
   TLDs and organization level domains, policy can only be published for the 
exact
   domain.  No method is available for such domains to express
   policy or receive feedback reporting for sub-domains.
   This missing method allows for the abuse of non-existent organizational-level
   domains and prevents identification of domain abuse in email.


The example section doesn't read like the rest of the draft and was hard for me 
to read through. Original:

   This would provide policy and feedback for mail sent from
   @gov.example, but not @tax.gov.example and there is no way to publish
   an organizational level policy that would do so.  While, in theory,
   receivers could reject mail from non-existent domains, not all
   receivers do so.  Non-existence of the sending domain can be a factor
   in a mail delivery decision, but is not generally treated as
   definitive on its own.

Again my stab:

   This DMARC record provides policy and a reporting destination for mail sent 
from
   @gov.example. However, due to DMARC's current method of discovering and 
applying
   policy at the organizational domain level, the non-existent organizational 
domain of @tax.gov.example
   does not and cannot fall under a DMARC policy.


I don't have too much more, I just got just caught up in the initial read. This 
paragraph contains a construct that was confusing to me:

   This memo provides a simple extension to DMARC [RFC7489] to allow
   operators of Public Suffix Domains (PSDs) to express policy for
   groups of subdomains, extends the DMARC [RFC7489] policy query
   functionality to detect and process such a policy, describes receiver
   feedback for such policies, and provides controls to mitigate
   potential privacy considerations associated with this extension.

^^^ why "groups of subdomains" and not just "subdomains"? One step further, why 
not "express policy at the level of the PSD that covers all organizational 
domains that do not explicitly publish DMARC records"?


OK, two more things:

2.3.  Longest PSD

   Organizational Domain (DMARC [RFC7489] Section 3.2) with one label
   removed.

^^^ "one left-most label removed"?


Last thing: Security considerations might call out DNS cache poisoning as a way 
to get reports for a PSD. Applies to vanilla DMARC too, but the scope and 
potential breadth of information with PSD-DMARC is really interesting. I 
imagine an attack that gets .COM listed into the PSD Registry for a specific 
report generator.. combined with cache poisoning and the poor report generator 
would probably explode at best.


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

Re: [dmarc-ietf] Endless Email Loops with Aggregate Reports

[Tim Draegen]

> On Jun 1, 2019, at 4:13 AM, Murray S. Kucherawy  wrote:
> 
> On Fri, May 31, 2019 at 10:55 AM Dilyan Palauzov  > wrote:
> Shall I submit an erratum to RFC7489?
> 
> I would, yes.  And this should certainly be recorded as something we need to 
> fix for standards track DMARC, whether by chasing down RFC7489 errata or via 
> a dedicated issue in this WG's tracker.

I did not see this item submitted as errata, so I put it into the tracker:

  https://trac.ietf.org/trac/dmarc/ticket/30

I'd like to float the idea that this scenario might be something operators 
address when they're generating reports (perhaps mentioned in DMARC Usage 
Guide?). 

That said, the NOTIFY=NEVER idea makes a lot of sense to me, but I have to 
admit I'm not exactly sure how easy it is for operators to set this. If its not 
super obvious and available everywhere for free, I have to assume this means 
it'll be partially deployed forever, which puts us back at square one.

Sending with an empty RFC5321.MAILFROM sort of turns DMARC reports into a form 
of DSN. Implications unknown!___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

Re: [dmarc-ietf] DMARCbis issue: Reporting URIs

[Tim Draegen]

> On May 27, 2019, at 3:32 PM, John Levine  wrote:
> 
> Section 6.3 says that ruf and rua tags can take any URI, but only
> define the meaning of a mailto: URI.  Either it should define some
> other URI schemes or it should say that only mailto: URIs are valid.
> 
> Back in the olden days there was an http or https scheme that we took
> out because it was ill specified, and nobody but me had tried to
> implement it.  If people are interested in an https PUT scheme it
> would be easy enough to define one, but only if someone says they want
> to use it.  For large reports it could be somewhat faster than mailto
> both because the report body isn't base64 encoded and the report goes
> straight to the https server and doesn't get relayed as mail does.

FWIW I've added this to the tracker:

  https://trac.ietf.org/trac/dmarc/ticket/29#ticket

...and have mentioned the http POST scheme for TLSRPT. Feel free to add more 
context if you'd like.
=- Tim

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

Re: [dmarc-ietf] DMARCbis issue: failure report mail loops

[Tim Draegen]

> On May 27, 2019, at 3:22 PM, John Levine  wrote:
> 
> Apropos recent discussions, we could recommend that failure reports be
> rate limited per recipient both to break loops and to deter indirect
> mail bombing.

Hi John et al, I've added this suggestion to the tracker:

  https://trac.ietf.org/trac/dmarc/ticket/28

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

Re: [dmarc-ietf] DMARCbis issue: Separating reporting and policy

[Tim Draegen]

> On May 30, 2019, at 2:13 PM, Murray S. Kucherawy  wrote:
> 
> On Wed, May 29, 2019 at 10:13 AM John R Levine  > wrote:
> As far as I can tell your proposal to break the document in two has 
> gotten no support at all.  Can we stop now?
> 
> What's on topic for the group and what isn't is the purview of the co-chairs 
> and the charter.  Let's please not stifle discussions before they die on 
> their own absent chair action to the contrary.

FWIW, one reason why the document lists the XML today is to emphasize the 
importance of this reporting piece.

A few people are fond of saying: email receivers can do whatever the heck they 
want with their email. Part of DMARC's "social contract" between domain owners 
and email receivers is to allow email receivers to implement DMARC's policy 
model "safely" by means of telling domain owners via reporting what the email 
receivers are doing.

In other words, the model works as email receivers can push support burden back 
to domain owners *if* aggregate reporting is in place. As simple as it might 
sound, keeping the XML parts in the 'core' document is (was?) supposed to make 
it very clear what parts should be considered required.

-= Tim

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

[dmarc-ietf] Publication has been requested for draft-ietf-dmarc-rfc7601bis-03

[Tim Draegen]

Tim Draegen has requested publication of draft-ietf-dmarc-rfc7601bis-03 as 
Proposed Standard on behalf of the DMARC working group.

Please verify the document's state at 
https://datatracker.ietf.org/doc/draft-ietf-dmarc-rfc7601bis/

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

Re: [dmarc-ietf] I-D Action: draft-ietf-dmarc-rfc7601bis-03.txt

[Tim Draegen]

> On Aug 23, 2018, at 2:39 AM, Murray S. Kucherawy  wrote:
> 
> This is the WGLC result.  Tim sent me privately a large number of edits which 
> I cherry picked for things that were broken or obviously wrong and punted on 
> stuff that seemed less than that.  Tim, feel free to argue harder for 
> anything I passed over for inclusion.
> 
> Apart from that, I think this is good to go; everything else that appeared to 
> meet consensus was included.

Righto! Thank you Murray for the attention to detail.

I’ll will not be arguing for additional changes. Onward with shepherding..

=- Tim


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

Re: [dmarc-ietf] WGLC on draft-ietf-dmarc-rfc7601bis-02

[Tim Draegen]

> On Aug 3, 2018, at 7:03 AM, Murray S. Kucherawy  wrote:
> 
> I feel like we're making a lot more edits here than the WG intended to make.  
> It's fine if the WG wants to turn this into a larger editorial pass, but I 
> thought the updates here were tightly scoped before, namely just enough to 
> allow ARC to do what it needs.

I supplied a list of editorial + bug fixes. IMO there's a fuzzy line between 
fixing errors, removing ambiguity, and de-torturing sentences for future 
readers.

I'm also a fan of using tight scoping to keep focus, but need to point out that 
this WG has relaxed scope in the past to take on far more challenging work. 
Given that no document is ever taken on purely for editorial fixes, I'm OK with 
correcting the confusing bits while the door is open.

-= Tim



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

Re: [dmarc-ietf] WGLC on draft-ietf-dmarc-rfc7601bis-02

[Tim Draegen]

To get an early start on shepherding the draft, I gave the draft a 
top-to-bottom review with an eye towards readability.

To ease the editor's burden, I'm avoiding posting a wall of diffs and have 
opted for sending changes directly to the editor for consideration. I'll leave 
it up to the editor to flag any changes that need may need discussion.

=- Tim

> On Jul 15, 2018, at 2:04 PM, Barry Leiba  wrote:
> 
> So begins Working Group Last Call (WGLC) on draft-ietf-dmarc-rfc7601bis-02.
> 
> Please review the latest version:
> https://datatracker.ietf.org/doc/draft-ietf-dmarc-rfc7601bis/
>  and send comments to the DMARC working group mailing list by 3 August.
> 
> If you review it and think it's ready to go and you have no comments,
> please post that as well.
> -- 
> Barry, DMARC chair

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

Re: [dmarc-ietf] "next steps?" (was: Re: Agenda for IETF 101 DMARC session)

[Tim Draegen]

On Mar 13, 2018, at 9:42 AM, Dave Crocker  wrote:
> 
>>   Phase III:
>>  Review and refinement of the DMARC specification
> 
> Is there technical work on the base specification that would improve it?

The bug tracker contains a few items around clarification, removing ambiguity, 
correcting minor mistakes. Nothing major.

I was expecting someone to come up with a new tag that defined a mechanism for 
exception querying. EG, I have a piece of email that falls under a DMARC record 
where the Domain Owner is telling me I can query some resource to figure out if 
the identifier combination is OK. Aside from hallway conversation, haven't seen 
anything like it yet.

>>  Completion of Guide on DMARC Usage
> 
> What will it take to complete this doc?

Focus & cycles. The document is meant for future implementors. There has been 
*some* leg work done to collect information. There was talk of rechartering to 
remove this deliverable, but I hope that has been addressed.

=- Tim

> 
> One example would be a spec revision effort that targets clarification, 
> based on experience coding and deploying DMARC.
> 
> 
> I'll also suggest that it would help allay public concerns about DMARC to 
> be able to have this document include experience-based text about ARC usage; 
> both discussing how to use it and how effective it is.
> 
> d/

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

[dmarc-ietf] report from NL on need for DMARC standards track - open invite for participation

[Tim Draegen]

Hi all, last week I met with some of the folks involved with the Dutch 
Standardisation Forum. I'm reporting on a real need for the DMARC Working Group 
to make progress.

The Netherlands would like to include DMARC into their list of compulsory open 
standards. Also, in order for the European Commission to recognize DMARC as a 
standard, the technical specification needs to move from being an individual 
submission to being a standards track document.

It's pretty clear that the state of the DMARC working group is now blocking 
some facets of the adoption of DMARC. Our small group of dedicated volunteers 
are currently tackling ARC. We might need more people to be involved as our 
current volunteers can only do so much.

This is an open invitation to participate to move ARC faster, and to invite 
colleagues to get more people involved in the mainline work. Tell a friend!

If you know of people who would like to participate in this Working Group but 
are otherwise shy, please reach out to any of the chairs and they'll/we'll be 
happy to facilitate.

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

[dmarc-ietf] Usage Guide interview (ISP) with David Finger @ Seznam.cz

[Tim Draegen]

[This email is part of the series described here: 
https://www.ietf.org/mail-archive/web/dmarc/current/msg03671.html 
]

Usage Guide draft: 
https://www.ietf.org/id/draft-tdraegen-dmarc-usage-guide-00.txt 

Background: Seznam.cz is largest mailbox provider in Czech Republic. In 
operation since 1995. Started with email in ‘98. 8 million (monthly) active 
accounts. Seznam attempts to support technical standards. Not a lot of ISPs in 
Czech Republic; 60 ~million received daily emails directly to inboxes (not 
including blocked email). Began looking at DMARC ~2015, have been using as 
input into anti-spam, not 100% applied as per DMARC spec.

Experience: Began sending aggregate DMARC reports September 2017. Forensic 
reports are to follow. Implementation based on OpenDMARC library. No storage or 
logging issues. Capacity verification was performed beforehand, no issues. From 
a developer perspective very lightweight. From project management PoV, 
constraint was time in terms of priority against other projects.
Private DNS cache experienced no issue. SPF and DKIM checking already 
existed. DKIM was required for bulk senders to deliver email into Seznam since 
~3 years ago. DMARC viewed as next step to give senders picture of traffic.
Bulk senders vs primary post (transactional email falls into primary post). 
Senders instructed to use DKIM to differentiate between 
primary-post/transactional email and bulk email. (Bulk email guidance: 
https://fbl.seznam.cz/ )
Began with SPF, recommended for senders but not a requirement like DKIM is. 
Primary used as an input into anti-spam. SRS in use for past year.

Operational issues: biggest problem - pushing information to senders that DKIM 
is required. 6 months preparation time. Senders had trouble understanding DKIM 
and what was being asked (including developers).

½ of bulk senders reside in CZ. Bounce messages used to inform people that DKIM 
is now required. Help/support desk dealt with issues - guidance given to deploy 
DKIM. Couple of months of guidance… still, today, ~ half a million daily 
messages are bounced. Most ESPs do not notice that their email us bouncing 
(!).. That is, not measuring engagement at all.
Maybe the people receiving email do not notice the missing messages, 
and so everything is OK. :-7

Malformed email is given a separate signal and dealt with. 
All DKIM signatures are evaluated. All reported via DMARC.
Key length is not an issue due to recent DKIM deployments.
(Does OpenDMARC flag short key length issues?).
Hadoop used as log collection/data-warehousing.
DMARC stack implemented inhouse, no issues with communication of various DMARC 
inputs.

Hosting? Custom domains can be used with web interface.
Forwardings happens. If ARC can supply original authentication results, that 
would be useful.
IMAP/POP3 is available.
No decoration of authenticated email via webmail yet. DMARC will supply bits to 
build on and will act as carrot to get more people/institutions to deploy.
Things like DKIM are not very effective in pushing institutions to 
deploy. DMARC’s carrot might end up being little green icon for users to see. 
(Note carrots are needed as institutions often do not understand other 
benefits/requirements).

Forensic reports: OpenDMARC has library support to make sure Domain Owners 
wants the info. Requirements for GDPR are a big issue and has to be fully 
implemented. DMARC viewed as a way for senders to understand how to secure 
their own data in better ways.
GDPR is required; forensic reports do not bring along any additional 
requirements/work load.


No whitelists are maintained as exceptions to processing. ~5 years ago 
whitelisting was removed and replaced by reputation measures. No overrides are 
applied to DMARC policies. Instead, reputation ramps are best established using 
SPF, DKIM, and DMARC. Start as small trusted user, then ramp up. Users 
ultimately decide whether or not email is wanted.

Support inquiries go to contact address found in XML reports, gets added to 
existing help desk.

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

Re: [dmarc-ietf] ARC-Seal is meaningless security theatre

[Tim Draegen]

> On Aug 7, 2017, at 1:21 AM, Bron Gondwana  wrote:
> 
> A more cheap and nasty fix, assuming it's too late/complex to change the 
> protocol more, would be to keep AS, but change the validation to only require 
> checking the most recent AS, since validating the rest is meaningless.

Bron, thanks for sharing your insight. I don't think it's too late/complex to 
incorporate direct real world experience into the specification.

I tried to express my own attitude in the Prague meeting: the email space is 
special because it is huge. It doesn't make sense to pretend that it isn't. 
Instead, let's build tech to solve real problems, test it against the install 
base, and make the tech better based on what is learned.

AFAICT, ARC is at the very beginning of the "test it against the install base" 
phase.


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

Re: [dmarc-ietf] ARC Experimental goals

[Tim Draegen]

> On Jul 21, 2017, at 9:27 AM, Dave Crocker  wrote:
> 
> On 7/21/2017 6:17 AM, Tim Draegen wrote:
>> Dave, are you saying the production of a rich and useful BCP could mark the 
>> end of Experimental status?
> 
> Yes.

Makes sense to me. Perhaps the WG should start collecting information as new 
deployments are happening.

Some deployers are already sharing. Why not pipe what is learned directly into 
a BCP.. you know.. in real time?

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

Re: [dmarc-ietf] ARC Experimental goals

[Tim Draegen]

> On Jul 20, 2017, at 4:57 PM, Dave Crocker  wrote:
> 
> ARC produces a /chain/ of signatures.  There is essentially no operational 
> experience doing this in real time in the operational Internet.  We need to 
> learn what dependencies and what fragilities are relevant to its use.
> 

> Therefore, experimental experience with ARC needs to:
> 
> 1. Demonstrate use across a 'significant' range of different email 
> sending software, receiving software, mailing list packages, mailbox 
> operators and mailing list operators.
> 
> 2. Demonstrate robust survival of ARC signatures.
> 
> 3. Demonstrate useful error reporting behaviors.
> 
> 4. Demonstrate stable operational integration into mail filtering 
> engines, subject to a 'significant' array of usage policies -- or demonstrate 
> industry consensus on a small, stable set of policies.
> 

> When these demonstrations are made, it will be possible to write a usage BCP 
> that has rich and useful guidance for those wishing to deploy ARC.

Dave, are you saying the production of a rich and useful BCP could mark the end 
of Experimental status?

-= Tim

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

Re: [dmarc-ietf] DMARC mailing list policy with respect to DMARC bounces causing subscription suspensions

[Tim Draegen]

> On Jul 20, 2017, at 2:00 PM, Hector Santos  wrote:
> 
> Anyway, we been here and there already. I just find it interesting that it 
> has come to this new manual "unfriendly" administrative policy. It should to 
> be codify into the integrated specs and everyone will quickly see what needs 
> to be done.

It's true. For this list specifically, the fallout is impacting the group's 
ability to address the problem... which is ironic?

Also, the draft minutes 
(https://www.ietf.org/proceedings/99/minutes/minutes-99-dmarc-02.txt) mention:

>Alexey: Also planning workaround that rewrites  addresses, start
>experimenting in September.  Different  rewriting than existing
>patches.

..so the giant wheel is turning, albeit *slowly*.

=- Tim

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

[dmarc-ietf] current state of the DMARC Usage Guide

[Tim Draegen]

Hi all, in preparation for Thursday's in-person meeting, here's a summary of 
where the DMARC Usage Guide is at:

1) Thread on "Do we really need to do this?". Thread ends with "let's not do 
this unless there is missing documentation".
(https://mailarchive.ietf.org/arch/search/?email_list=dmarc&gbt=1&index=ii4ds1wcctfhUpbTmMeu8Nh0UHs)

2) Outline of approach to understanding if documentation is missing. Approach: 
get some Domain Owners, third party senders, and receivers to share operational 
experience:
https://mailarchive.ietf.org/arch/msg/dmarc/9Pks0yVkpjtxtqKsfUf-gRY9gyE
1st ESP: https://mailarchive.ietf.org/arch/msg/dmarc/76CoHb7KRYPOvRqrEuBn_KU1FZE
1st ISP: https://mailarchive.ietf.org/arch/msg/dmarc/ptWY1dFS7IcmpcGGW5vICJpzF_s

3) Question of reputation being attached to selectors, and if BCP/Usage Guide 
needs to fill a gap:
https://mailarchive.ietf.org/arch/search/?email_list=dmarc&gbt=1&index=LwQZxssf_aGqrh8VwXKoiGE0aKE
An open question:
https://mailarchive.ietf.org/arch/msg/dmarc/KKIATMeNnab8JA857XgMWOZPTOI

In message 
(https://mailarchive.ietf.org/arch/msg/dmarc/9Pks0yVkpjtxtqKsfUf-gRY9gyE) I 
wrote:
> I hope that by the next in person meeting, we can at least discuss if there is
> a "there there". If there isn't, it won't be for lack of trying.

It's still my opinion that only the surface of real operational experience has 
been scratched. Finding people, convincing them to be interviewed, booking 
time, doing the thing, and then posting to this list all takes time.

My view on the Usage Guide is that the WG originally carved out time to work on 
this to help future deployers avoid mistakes. It's not easy reaching "beyond 
the choir", but IMO it's worth doing.

HOWEVER, if I'm the one guy in the room that wants to work on this, No Problem, 
I'll keep working this outside of the WG.

=- Tim




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

Re: [dmarc-ietf] selectors in AAR.

[Tim Draegen]

> On Jul 6, 2017, at 9:25 PM, Seth Blank  wrote:
> 
> In the case of a direct mail flow, the receiver has all the needed 
> information from the SMTP connection and A-R payload to create a report. None 
> of this information is present once a message arrives at a receiver in an 
> indirect manner.
> 
> I would strenuously argue the charter's call for "eliminating the DMARC's 
> effects on indirect mail flows" requires that reporting - which is the 
> fundamental feedback mechanism for a sender - work properly under said fixes. 
> This is impossible for a receiver to do without ARC passing the information 
> along. And ARC has this transmission mechanism in its AAR, but we need to 
> make sure the appropriate information is in it.

It might be useful to show what the desired DMARC reporting looks like for 
email flows where ARC is at play.

For example, maybe "override" just shows "arc_at_work" with existing fields 
identifying the last hop (like is done today). In that case reporting works 
properly.

If there's a more robust presentation that is wanted, it would help the list to 
see an example. Maybe then people could follow along to see why the inclusion 
of selectors is necessary from a DMARC reporting perspective.

=- Tim

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

[dmarc-ietf] using selectors to identify sources

[Tim Draegen]

> On Jul 5, 2017, at 6:33 PM, Murray S. Kucherawy  wrote:
> 
> Based on discussions with Seth and Gene earlier, it sounds like the industry 
> has sadly not taken up the habit of key and selector rotation, and instead 
> the pairing of "s=" and "d=" now identifies a single source.  Ignoring the 
> obvious security problem this introduces, we're now talking about implicitly 
> formalizing this tuple as identifying a source.  This contradicts that 
> original intent.  In particular, if one were to develop reputation in this 
> way, then a key being rotated out takes the reputation with it; signers would 
> have to establish some procedure for doing so with substantial overlap so 
> that the new key can be "warmed".  Worse, in an emergency where a key is 
> compromised, that tuple's reputation irretrievably suffers.
> 
> How is this better than encouraging the industry to adopt the separation of 
> functions that was originally intended?

I just caught up on the "selectors in AAR" thread, but wanted to go back to 
this early statement about key rotation and pairing of "s=" and "d=" to 
identify a single source. Thus a new Subject: is born.

It's true key rotation is rare. People are figuring out how to do it, though. 
Due to the size and scope of email's installed base, it takes a really long 
time for the knowledge to slosh around the Internet. Using multiple CNAMEs, 
delegating sub-domains, even out-sourcing all things _domainkey.* is possible. 
Unfortunately there isn't good guidance on the pros and cons of each way, and 
so people implement quick and dirty 'cause they don't know any better.

Using selectors to identify a single source of email isn't right, IMO. Given 
the way things play out, once people are told that selectors are important 
because they're used to identify sources of email (doesn't even matter how true 
it is), then we'll be stuck with selectors being a component of reputation. 
People will make do with what they've got.

If nature abhors a vacuum, the missing piece is "what identifies a source?". 
Selectors might fill that hole unless real guidance is provided.

Using sub-domains to differentiate services works nicely. Today lack of clear 
guidance means a Domain Owner has to deal with a mashup of different ways to 
integrate with 3rd party senders. 3rd party senders make do with what they've 
got, and that is often very constrained.

Maybe such guidance should go into the "Usage Guide". Declaring which parts of 
the DMARC puzzle should be used to build reputation system seems pretty 
important if interoperability is the goal.

-= Tim

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

[dmarc-ietf] Usage Guide interview (ISP) with Vladimir Dubrovin @ Mail.Ru

[Tim Draegen]

[This email is part of the series described here: 
https://www.ietf.org/mail-archive/web/dmarc/current/msg03671.html]
 
Background: Mail.Ru is an early adopter of DMARC -- implementing the technical 
specification as part of the pre-public pilot group. As the largest provider of 
email in Russia, Mail.Ru sees a lot of spoofed email and maintains a strong 
desire to improve the state of email. From Mail.Ru’s  perspective, .COM email 
is almost all spam… outside of RU, email from .RU is typically spam. DMARC has 
been very useful in identifying real email to help with this problem. While 
DMARC is mostly positioned as a protection against phishing, in case of Mail.Ru 
primary reason to implement DMARC was protection against spam/secondary spam 
and improve deliverability, because regional domains like .ru are often 
blacklisted outside of Russia due to high spam/ham values. Fraud is also an 
issue. To cut down on fraud, Mail.Ru works with business and government 
organizations to implement DMARC. For example, Russian Federa Tax Service sees 
a lot of phishing; Mail.Ru worked with them to protect domain from abuse.
 
Vladimir Dubrovin is a Mail.Ru technical advisor and heads up DMARC 
implementation for last few years. Mail.Ru acts as a resource to push DMARC 
adoption within Russia.
 
Experience: DMARC used at Mail.Ru for its own domains and also inbound 
processing/filtering.
 
Filtering: No significant issues aside from typical issues related to dealing 
with large amounts of traffic. In the beginning, very little impact from 
adopting DMARC due to little global adoption, now it is widely used. There are 
exceptions that must be maintained, though. EG, because Mail.Ru has been around 
for a long time, we see lots of older traffic going through forwarding/lists. 
Exceptions-lists originally constructed by analyzing log files and based on 
user’s reports. We inspect message types and apply exceptions where it makes 
sense. Messages from ESPs with broken DMARC are not accepted for domain with 
DMARC reject policies due to the nature of the email flows - they do not flow 
through mailing lists for example.
 
If users report problems regarding mailing lists, we can add exceptions for the 
problem. This does not happen very often… maybe ½ a year ago something was 
added. Exceptions added apply to all users.
 
Exceptions are keyed off of DKIM signature and IP. In the future we’ll add 
support for ARC but it will be treated just like DKIM+IP exceptions… no 
expected improvements except for very unusual circumstances.
 
It is not unusual to received malformed email that is legitimate. Typically we 
show users a warning if the email might have been spoofed. Attacks based on 
malformed email (Misformed of multiple From: headers, eg) are common.. as are 
emails that are legitimate but sent through a convoluted path. Also homograph 
attacks from non-existant domains.. we display warnings to users via our 
web-based interface. We also indicate the failure via Authentication-Results to 
provide an information for MUA, but we do not know of any email clients that 
render authentication results outside of web-based interfaces.
 
Exim-based SPF and DKIM implementations: No issues today. Exim has a DKIM bug 
where multiple signatures from same domain with 1 valid and 1 broken didn’t 
work. Fixed internally and submitted a patch to exim.
 
A Mail.RU-hosted short DKIM key was discovered and fixed. Even though the DKIM 
key was unused, criminals could exploit it. In the filtering context, currently 
not collecting statistics if senders are using weak keys… DKIM adoption 
happened fairly late in Russia and so existing implementations are almost all 
1024 or greater in RU. Haven’t (yet!) seen cases where weak keys are exploited. 
Balance for us is between possibility of exploit vs working with today’s 
environment.
 
For SPF, we ignore “+all” policies that abusers like to use, and might add 
negative weight to such SPF records. Tricky because some records are 
effectively “+all” but using huge netblocks. For this reason, anti-spam layer 
improved to process SPF record in addition to SPF results (results are 
validated by MTA).
 
Filtering for business users is the same for freemail users. Freemail users are 
protected by mail.ru DMARC policy, but business users’ domains are not 
automatically given DMARC policy. In business administration panel, a mark is 
given in the UI to indicate problems with SPF and DKIM, DMARC record 
constructor is under development. 
 
Today in our web interface, warnings of suspicious email are only displayed if 
DMARC record is in place. In near future, warnings will be displayed even if 
DMARC record is not in place, starting if messages fails any authentication 
(e.g. SPF). We’ll end by displaying warnings if email lacks authentication for 
domains that are present in an email. Sensitive email such as from a banks are 
given special treatment/display.
 
Reporting: only aggregate reports are sent. For

[dmarc-ietf] Usage Guide interview (ESP) with Alwin de Bruin @ Measure Mail

[Tim Draegen]

[This email is the first of a series described here: 
https://www.ietf.org/mail-archive/web/dmarc/current/msg03671.html Thanks much 
to Alwin for being the first to volunteer and to help smooth out the rough 
spots.]

Background: Measure Mail is a Netherlands-based Email Service Provider 
operating since 2001. Within Measure Mail Alwin is responsible for operations. 
The company strives to remain up to date with changes in the email ecosystem. 
Outside of Measure Mail Alwin is heavily involved in Netherlands 
standardization communities to establish technology guidelines for ESPs and 
government email requirements. Alwin has advocated for DMARC within Netherlands 
circles since its public release.

Experience:
From company perspective, making customers recognizable to the recipients of 
email is primary. Two points:
• Cannot interfere with existing email infrastructure.
• Cannot settle for “sent on behalf of” in a UI, which lead to the 
required use of sub-domains. Customers are provided with DNS settings to allow 
Measure Mail to send email using a customer’s sub-domain.

Use of sub-domains allows us to make email appear to come from customer, 
including addresses, embedded links, and other branding. Ensuring that all 
domain identifiers in an email are aligned helps make email obvious and easy to 
deliver. Customers accept this explanation as it is easy to understand.

Sending DNS settings to customers can be quite complex. However, the 
requirement to implement DNS-changes leads to better customers in terms of us 
servicing slightly more technically savvy customers, but also tends to exclude 
very small businesses that do not have resources to deal with DNS configuration.

Making DNS changes easier for customers is something we’ve focused on over the 
past few years. In this way, we’ve arrived at requiring DNS changes only once 
during onboarding. This appears to be a trend among the market.

Customer use of DMARC policies has had little impact on our service. For the 
sub-domains that customers provide to us, we originally placed DMARC records to 
help monitor email delivery. By design we see little impact to our service due 
to customers publishing DMARC policies.

When customers publish their own DMARC records, we ask our customers to provide 
us with their reporting address so that we can forward sub-domain specific 
reports to the customer. In this way the customer gets a complete picture. 
Otherwise the customer might not see the complete picture.

Strict vs Relaxed mode: haven’t run into any issues, but mainly because we work 
with customers early. Plus, we have DMARC records in place at sub-domain which 
we operate in.

SPF considerations: we maintain an include that customers use. By doing this, 
we can maintain the real SPF record without requiring customer changes. Also, 
we use dedicated sub-domains and so configuration avoids top-level SPF record 
issues.

DKIM considerations: key rotation appears to be relatively new in the market. 
Our own infrastructure is ready for key rotation. Customers are being upgraded 
to use newer functionality that allows for no-touch key rotation. But, this is 
a process where older customers need to perform DNS changes to get to the “no 
more touch” world.

Key sizes: we’ve always used 1024 bit keys, with our newer infrastructure using 
2048 keys. Once customers are on newer infrastructure, the upgrade to 2048 bit 
keys is transparent.

DKIM options: we use default DKIM settings when possible. Default headers that 
are signed mirror what is published in DKIM spec. Simple body canonicalization. 
DKIM timestamp included.

Policy implications: we discuss DMARC with customers if the subject comes up, 
and when customers are onboarded. People are guided to the Wikipedia articles 
on DMARC to learn about the basic stuff. DKIM sometimes requires additional 
explanation.

Other thoughts on Domain Owner & ESP interaction? We’re thinking of 
implementing DMARC reporting for the bounce messages that we receive to help 
communicate status to bounce-originating organization.

Overall, we don’t have issues with DMARC. This is likely due to our pre-DMARC 
understanding that domain alignment is common sense approach to sending 
customer email.
(end)

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

[dmarc-ietf] Fwd: New Version Notification for draft-tdraegen-dmarc-usage-guide-00.txt

[Tim Draegen]

TOP POST because this is a notification.

It's my understanding that people want to share their DMARC operational 
experience. However, it appears that people in operational roles simply do not 
have the time to participate directly in the lightly structured IETF context. 

To see if there is any way to get experience shared despite the gap, I'll be 
using this draft and interviewing people with operational experience to at 
least get their insight posted to the list.

As you can see, the draft is organized into 3 audiences: domain owners, 
senders, and receivers. I'll try to get at least a few from each audience. I've 
got some volunteers already, and will push each one to the list as they happen.

This is the best I can do to determine if there is momentum to be had. I hope 
that by the next in person meeting, we can at least discuss is there is a 
"there there". If there isn't, it won't be for lack of trying.




> Begin forwarded message:
> 
> From: internet-dra...@ietf.org
> Subject: New Version Notification for draft-tdraegen-dmarc-usage-guide-00.txt
> Date: June 17, 2017 at 7:32:26 AM EDT
> To: "Tim Draegen" 
> 
> 
> A new version of I-D, draft-tdraegen-dmarc-usage-guide-00.txt
> has been successfully submitted by Tim Draegen and posted to the
> IETF repository.
> 
> Name: draft-tdraegen-dmarc-usage-guide
> Revision: 00
> Title:DMARC Interoperability Usage Guide
> Document date:2017-06-17
> Group:Individual Submission
> Pages:8
> URL:
> https://www.ietf.org/internet-drafts/draft-tdraegen-dmarc-usage-guide-00.txt
> Status: 
> https://datatracker.ietf.org/doc/draft-tdraegen-dmarc-usage-guide/
> Htmlized:   
> https://tools.ietf.org/html/draft-tdraegen-dmarc-usage-guide-00
> Htmlized:   
> https://datatracker.ietf.org/doc/html/draft-tdraegen-dmarc-usage-guide-00
> 
> 
> Abstract:
>   Domain-based Message Authentication, Reporting, and Conformance
>   (DMARC) allows for the expression of domain-level policies and
>   preferences for message validation, disposition, and reporting
>   between mail-originating and mail-receiving organizations.  This
>   usage guide presents strategies for successful interoperation of
>   historically disparate mail systems in the presence of domain-level
>   policies.
> 
> 
> 
> 
> Please note that it may take a couple of minutes from the time of submission
> until the htmlized version and diff are available at tools.ietf.org.
> 
> The IETF Secretariat
> 

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

Re: [dmarc-ietf] Proposal: Writing a DMARC usage guide is not a good task for this WG

[Tim Draegen]

> On Jun 1, 2017, at 5:52 AM, Alexey Melnikov  wrote:
> 
> Is there an expired or not yet posted draft on DMARC usage? I think looking 
> at any written text will help inform the decision.

I brainstormed a bit while at M3AAWG with a few people about the DMARC Usage 
Guide. Then I got the opportunity to convert notes into a draft while pulling 
an all nighter in Chicago O'Hare.

I'll post a draft and then start a new thread with the details.

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

Re: [dmarc-ietf] Proposal: Writing a DMARC usage guide is not a good task for this WG

[Tim Draegen]

> On May 31, 2017, at 8:47 AM, Barry Leiba  wrote:
> 
> I agree with this.  If there's stable documentation on DMARC usage
> that we can cite, there's little value in adding our own, which is
> likely to end up diverging from the others.
> 
> Does anyone think we *should* proceed with writing this?

A draft has been started on this, with slow progress. The draft aims to fill 
documentation gaps based on how domain-level policies can impact organizations 
(across the whole email food chain) and how to best manage 
impact/interoperability.

The original intent of the document was to share operational experience from 
the PoV of Domain Owners, third party senders, and email receivers/processors. 
For example, if a third party sender wants to start sending on behalf of Domain 
Owners, the document would describe how to do this in a ~normal way. The 
production of the document was supposed to get people to share experience, 
especially in areas outside of commercial activity.

That said, given the WG's history of thin participation, I'm OK with dropping 
the Usage Guide. The existing gaps in documentation will be filled outside of 
the IETF. On the one hand I'm a believer that an IETF-produced Usage Guide is 
better for interoperability than a collection of to-be-published documents 
spread throughout the Internet. On the other hand, forcing a bunch of people to 
work on a draft isn't how I like to spend my Internet time.

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

[dmarc-ietf] Usage Guide update

[Tim Draegen]

A minor update: an Abstract, Intro, and Outline have been written up. Half a 
dozen people (those that previously volunteered on this list) are putting meat 
on the bones now to get an initial reviewable draft into place.

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

Re: [dmarc-ietf] looking for collaborator for Usage Guide

[Tim Draegen]

> On Feb 24, 2017, at 10:30 AM, Mike Jones  wrote:
> 
> So my recommendation for anyone interested is to read this, 
> https://tools.ietf.org/html/draft-crocker-dmarc-bcp-03 
> .   We can 
> collaborate on where it is incomplete or outdated, and revise as needed.

Thanks Mike, I'll review too.

I'm starting off with an outline for people to review based on the content of 
the linked draft and what is spelled out as being needed in the charter.

Once the outline is ~OK, people can bite off chunks to fill out. Enough people 
from different areas have volunteered to make this approach viable.

=- Tim

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

[dmarc-ietf] looking for collaborator for Usage Guide

[Tim Draegen]

Hi all, I'm looking to collaborate with someone on the creation of the DMARC 
Usage Guide. The Usage Guide is mentioned in the WG Charter as "3. DMARC Usage":

  https://datatracker.ietf.org/wg/dmarc/charter/

If you or a colleague would be interested in this work, please contact me off 
list. Thanks!
=- Tim


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

[dmarc-ietf] phase 1 is done

[Tim Draegen]

This working group's "phase 1" is now done.

The Chairs will be shepherding the phase 1 interoperability draft:

  https://trac.tools.ietf.org/html/draft-ietf-dmarc-interoperability

The WG will now move ahead to phase 2:

  https://trac.tools.ietf.org/wg/dmarc/trac/wiki/MilestoneTwoWiki

When discussing methods and techniques that address an interoperability issue, 
please explicitly reference the issue from the 
draft-ietf-dmarc-interoperability draft.  This will allow for easier tracking 
of issues & proposed fixes by volunteers a lot easier.

=- Tim

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

Re: [dmarc-ietf] Are we done with last call on the interop document?

[Tim Draegen]

Kurt, I believe so.  AFAICT, there was one paragraph you were runnin down, but 
if you're asking, I'm assuming that's it.   Right?

=- Tim


> On Feb 12, 2016, at 3:32 PM, Kurt Andersen (b)  wrote:
> 
> Since there have been no further comments since this version was posted, does 
> that mean that we are done with "last call"?

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

Re: [dmarc-ietf] Clarification question on handling multiple domains in RFC5322.from (section 6.6.1)

[Tim Draegen]

> On Jan 18, 2016, at 12:49 PM, Kurt Andersen (b)  wrote:
> 
> Am I misunderstanding the recommended algorithm?
> 

Maybe the example of @crime.net  and @bank.com 
 might add clarity.  If both have a p=reject policy, and only 
@crime.net  successfully passes the DMARC check, it would be 
wise to enforce @bank.com's reject policy, no?

=- Tim

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

Re: [dmarc-ietf] Responses to comments on draft-ietf-dmarc-interoperability-08.txt

[Tim Draegen]

> On Nov 7, 2015, at 9:01 PM, Kurt Andersen (b)  wrote:
> On the flipside, I don't see what value they add; the ones that gain 
> consensus will be published in their own right, and the details of the ones 
> that don't probably aren't interesting to later readers anyway.
> 
> -MSK
> 
> I'm OK either way. Tim, would you care to weigh in as the WG chair? It's an 
> easy change to make and it would be nice to close out this milestone. What 
> about demoting the I-D citations to an Appendix?


Not as a WG Chair (as I don't think that matters here), but IMO going with 
Murray's suggestion is wise. 

The idea of moving the I-D citations to an Appendix is immediately appealing, 
but I think in the future such an Appendix will just cause confusion.

=- Tim


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

Re: [dmarc-ietf] Two new internet-drafts related to forwarded email

[Tim Draegen]

> On Oct 17, 2015, at 9:11 AM, Kurt Andersen  wrote:
> 
> As one of the editors for the interop document, I have already reviewed it 
> :-) 

Yes!  I'm hoping your A.R.C. colleagues will chime in, too.

> 
> The ARC spec is explicitly designed to help preserve authentication results 
> across multi-hop mail transfers in all of the cases where the intermediaries 
> participate. I would like to add a section to the interop document talking 
> about it, but thought that might be presumptuous. If not, I'll prep an update.


The word "intermediary" doesn't exist in the current interop issues draft, so 
if the A.R.C draft is a response to a sub-set of the issues discussed in the 
interop document, it would be great to explicitly mention which issues are 
addressed.  This will make it a lot easier to go through once the WG finishes 
its current task.

Getting the other A.R.C. editors (and perhaps other A.R.C. participants?) to 
review and comment on the 07 interoperability draft:

  https://tools.ietf.org/html/draft-ietf-dmarc-interoperability-07 


..would help this WG finish its current task.  Without review and comment of 
the documented issues, it will be hard to take seriously any efforts to address 
said issues.

-= Tim


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

Re: [dmarc-ietf] Two new internet-drafts related to forwarded email

[Tim Draegen]

> On Oct 16, 2015, at 10:41 AM, Kurt Andersen  wrote:
> 
> Will look forward to feedback from any interested parties.

Hi Kurt,

Can you and the editors of these documents review the interoperability issues 
doc (now in WG last call):

  https://tools.ietf.org/html/draft-ietf-dmarc-interoperability-07 


?

Once that's done, maybe the editors of the A.R.C. document can share where it 
fits into the issues outlined in the interoperability issues doc.

Mainly, though, I'm keening on getting reviews in of the WG doc ASAP.

-= Tim

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

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

[Tim Draegen]

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

Re: [dmarc-ietf] Ping?

[Tim Draegen]

> On Jul 16, 2015, at 2:00 AM, Murray S. Kucherawy  wrote:
> 
> Hey, so uh, who's waiting on whom for what here?

The interoperability issue draft has outstanding edits for version 4, with an 
emphasis on finishing Section 4:

  http://trac.tools.ietf.org/id/draft-ietf-dmarc-interoperability-04.txt

The ball is in the editors' court to finish Section 4.

=- Tim

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

Re: [dmarc-ietf] I-D Action: draft-ietf-dmarc-interoperability-04.txt

[Tim Draegen]

> On Jun 9, 2015, at 11:44 AM, Franck Martin  wrote:
> 
> As comments are dying out, are we close to a last call?


There will be another revision to pick up a small batch of grammar nits.  
Reviews now are appreciated but if you're keen on grammar nits, you might hold 
off.

=- Tim

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

Re: [dmarc-ietf] RFC 7489 on Domain-based Message Authentication, Reporting, and Conformance (DMARC)

[Tim Draegen]

> On Mar 18, 2015, at 4:30 PM, Murray S. Kucherawy  wrote:
> 
> On Wed, Mar 18, 2015 at 1:19 PM, Tim Draegen  <mailto:t...@eudaemon.net>> wrote:
> Hi Murray & Elizabeth, thanks for wrestling this through the process.  The 
> Working Group can now adopt this as input.
> 
> /goes off to figure out which buttons need to be pushed
> =- Tim
> 
> 
> I have to resubmit it as "draft-ietf-dmarc-base" and then you guys have to 
> approve it in, assuming you still want me to act as editor.  Did you want to 
> do that right away or wait until the earlier milestones have been met?

You might as well do it right away.  The earlier milestones are not coupled to 
the DMARC base draft.

=- Tim

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

Re: [dmarc-ietf] RFC 7489 on Domain-based Message Authentication, Reporting, and Conformance (DMARC)

[Tim Draegen]

Hi Murray & Elizabeth, thanks for wrestling this through the process.  The 
Working Group can now adopt this as input.

/goes off to figure out which buttons need to be pushed
=- Tim


> On Mar 18, 2015, at 4:08 PM, Murray S. Kucherawy  wrote:
> 
> FYI:
> 
> -- Forwarded message --
> From: mailto:rfc-edi...@rfc-editor.org>>
> Date: Wed, Mar 18, 2015 at 1:04 PM
> Subject: RFC 7489 on Domain-based Message Authentication, Reporting, and 
> Conformance (DMARC)
> To: ietf-annou...@ietf.org , 
> rfc-d...@rfc-editor.org 
> Cc: drafts-update-...@iana.org , 
> rfc-edi...@rfc-editor.org 
> 
> 
> A new Request for Comments is now available in online RFC libraries.
> 
> 
> RFC 7489
> 
> Title:  Domain-based Message Authentication, Reporting, and
> Conformance (DMARC)
> Author: M. Kucherawy, Ed.,
> E. Zwicky, Ed.
> Status: Informational
> Stream: Independent
> Date:   March 2015
> Mailbox:superu...@gmail.com ,
> zwi...@yahoo-inc.com 
> Pages:  73
> Characters: 162707
> Updates/Obsoletes/SeeAlso:   None
> 
> I-D Tag:draft-kucherawy-dmarc-base-12.txt
> 
> URL:https://www.rfc-editor.org/info/rfc7489 
> 
> 
> Domain-based Message Authentication, Reporting, and Conformance
> (DMARC) is a scalable mechanism by which a mail-originating
> organization can express domain-level policies and preferences for
> message validation, disposition, and reporting, that a mail-receiving
> organization can use to improve mail handling.
> 
> Originators of Internet Mail need to be able to associate reliable
> and authenticated domain identifiers with messages, communicate
> policies about messages that use those identifiers, and report about
> mail using those identifiers.  These abilities have several benefits:
> Receivers can provide feedback to Domain Owners about the use of
> their domains; this feedback can provide valuable insight about the
> management of internal operations and the presence of external domain
> name abuse.
> 
> DMARC does not produce or encourage elevated delivery privilege of
> authenticated email.  DMARC is a mechanism for policy distribution
> that enables increasingly strict handling of messages that fail
> authentication checks, ranging from no action, through altered
> delivery, up to message rejection.
> 
> 
> INFORMATIONAL: This memo provides information for the Internet community.
> It does not specify an Internet standard of any kind. Distribution of
> this memo is unlimited.
> 
> This announcement is sent to the IETF-Announce and rfc-dist lists.
> To subscribe or unsubscribe, see
>   https://www.ietf.org/mailman/listinfo/ietf-announce 
> 
>   https://mailman.rfc-editor.org/mailman/listinfo/rfc-dist 
> 
> 
> For searching the RFC series, see https://www.rfc-editor.org/search 
> 
> For downloading RFCs, see https://www.rfc-editor.org/rfc.html 
> 
> 
> Requests for special distribution should be addressed to either the
> author of the RFC in question, or to rfc-edi...@rfc-editor.org 
> .  Unless
> specifically noted otherwise on the RFC itself, all RFCs are for
> unlimited distribution.
> 
> 
> The RFC Editor Team
> Association Management Solutions, LLC
> 
> 
> 
> ___
> 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

[dmarc-ietf] interoperability draft for review

[Tim Draegen]

Hi all,

Frank, Eliot, and myself have finished up a first cut at the WG’s 1st real 
deliverable:
• Document describing interoperability issues with DMARC and indirect 
mail flows and possible methods for addressing them.

Please review at your convenience and submit comments, feedback, and 
suggestions for text to this list.  Frank and/or Eliot will be folding in 
edits.  A serious effort to cast issues in the language of RFC 5598 was made.

Find it here:  
https://datatracker.ietf.org/doc/draft-ietf-dmarc-interoperability/

Our aim is to have this document ready for publication by end of February.

Have fun!
=- Tim

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

Re: [dmarc-ietf] ... and two more tiny nits, while I'm at it

[Tim Draegen]

> On Jan 17, 2015, at 12:00 PM, Hector Santos  wrote:
> 
> I have two concerns.
> 
> It seems you "jumped the gun" to accept the RFC 4408 obsolete idea. Is 7208 
> backward compatible or not?  Does DMARC require 7208 operations or 4408 
> operations?
> 
> And is this -12 publication "worthy" of even considering for implementation?  
> Or should we wait for the more "solid specification?"

Hi Hector, if you review:

  https://www.rfc-editor.org/rfc/rfc7208.txt

..you'll see at the very top "Obsoletes: 4408".  If there are discrepancies 
between 4408 and 7208, it's best to file an errata (erratum?):   
http://www.rfc-editor.org/how_to_report.html

DMARC implementations are already in the wild and deployed.  Input to the 
existing specification will be largely based on working implementations.  You 
might have your own reasons for waiting for this WG to review the DMARC base 
draft, but if you want to provide input based on operational & implementation 
experience, it's probably best to not wait.

=- Tim



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

Re: [dmarc-ietf] ... and two more tiny nits, while I'm at it

[Tim Draegen]

> On Jan 16, 2015, at 11:08 PM, Murray S. Kucherawy  wrote:
> 
> Would the co-chairs object to beginning to track these items using the WG's 
> tracker?  If and when we do decide to crack open the base document for a 
> Proposed Standard revision, we'd already have an inventory of topics to 
> consider.  It would also help to keep the discussion on this list focused on 
> active topics now that the base draft is "done".

No objection — please do use the WG’s tracker for these items.  Anne’s thorough 
review will be picked up (and not rediscovered!) if we’ve got an obvious place 
to start from.

=- Tim

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

[dmarc-ietf] update on 1st draft

[Tim Draegen]

Heyo all,

The WG's 1st draft (documenting interoperability issues between DMARC and 
indirect email flows plus possible ways to address them) should be ready for 
WG-wide review come mid week.

Due to the holidays this work was slow to get off the ground, but it's shaping 
up nicely now.

=- Tim

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

Re: [dmarc-ietf] milestone 1 *almost* done

[Tim Draegen]

> On Nov 21, 2014, at 1:54 PM, Rolf E. Sonneveld  
> wrote:
> 
> does this mean that any work/solutions will not be discussed on this list, 
> before a reviewable draft is ready? If so, please add me to the discussion 
> group.

No, I was not clear.  Discussion of solutions will happen on the mailing list 
-- I was referring to the act of cramming the good bits of the discussion 
(text, edits, making sure people aren't duplicating sections) into a draft.  

If you're NOT interested in editing, it will be business as usual on the WG 
list.

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

Re: [dmarc-ietf] milestone 1 *almost* done

[Tim Draegen]

On Nov 21, 2014, at 1:50 PM, Douglas Otis  wrote:
> 
> On Nov 21, 2014, at 9:56 AM, Tim Draegen  wrote:
> 
>> WG,
>> 
>> PS.  A group of editors spontaneously formed during the in-person meeting.  
>> The group will tackle Milestone 2 — which is to transform issues learned and 
>> documented in Milestone 1 + proposed solutions for each into a real 
>> reviewable draft.  This is not a closed group, so if you’d like to be 
>> actively involved, just say so.
> 
> Dear Tim,
> 
> Please include me in the solution discussions.

Hi Doug,

Discussion of solutions will happen on the mailing list -- I was referring to 
the act of cramming the good bits of the discussion (text, edits, making sure 
people aren't duplicating sections) into a draft.  

If you're NOT interested in editing, it will be business as usual on the WG 
list.

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

[dmarc-ietf] milestone 1 *almost* done

[Tim Draegen]

WG,

The work found here:

  http://trac.tools.ietf.org/wg/dmarc/trac/wiki/MilestoneOneWiki 


..is almost complete.  However, there is a note (reinforced by feedback during 
the recent in-person meeting) to recast the collected issues in terms of RFC 
5598.  Once this recasting is done, Milestone 1 will be officially met.

If you’re handy with the language found in RFC 5598, please consider helping 
out.  Getting the language correct now will only make everything better later 
on.

Co-chair,
=- Tim

PS.  A group of editors spontaneously formed during the in-person meeting.  The 
group will tackle Milestone 2 — which is to transform issues learned and 
documented in Milestone 1 + proposed solutions for each into a real reviewable 
draft.  This is not a closed group, so if you’d like to be actively involved, 
just say so.



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

Re: [dmarc-ietf] slides for Friday session

[Tim Draegen]

> On Nov 14, 2014, at 3:09 AM, Brett McDowell  wrote:
> 
> "It will also provide technical implementation guidance and review possible 
> enhancements elsewhere in the mail handling sequence that could improve DMARC 
> compatibility."
> 
> Is this exercise within the scope of Milestone 2 [2], i.e. are we going to 
> provide technical guidance elsewhere in the mail handling sequence (e.g. 
> mailing lists)

Hi Brett, yes, this is exactly what milestone 2 concerns.

> or are we only going to look at changes to dmarc-base [3]?

Focus on changes to the base spec comes later.___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

[dmarc-ietf] slides for Friday session

[Tim Draegen]

Slides for tomorrow’s session can be found here:

  http://www.ietf.org/proceedings/91/slides/slides-91-dmarc-0.pdf

More information on how to attend can be located from day's agenda/schedule:

  http://tools.ietf.org/agenda/91/#FRIDAY

=- Tim

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

Re: [dmarc-ietf] Indirect email flows

[Tim Draegen]

> On Nov 12, 2014, at 10:59 AM, Franck Martin  wrote:
> 
> Could I request the list admins, to drop the subject tagging and the footer 
> on this list? And if possible remove the removal of the HTML?

No.


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

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

[Tim Draegen]

> On Nov 8, 2014, at 8:38 PM, Franck Martin  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!
___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

[dmarc-ietf] draft IETF 91 WG agenda up for review & input

[Tim Draegen]

Hi, this WG’s IETF91 agenda is up for review:

  http://www.ietf.org/proceedings/91/agenda/agenda-91-dmarc 


If you have comments, suggestions, or modifications, please feel free to reply 
here or if you're shy, reply privately.

1/2 of this WG's chair,
=- Tim

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

[dmarc-ietf] End of thread! was: Re: wiki vs. list?

[Tim Draegen]

> On Oct 29, 2014, at 7:20 PM, Hector Santos  wrote:
> 
> If they are going to rewrite, then at the very least we MUST make 3rd party 
> protocol options and algorithms available as well to ALL implementators as 
> part of the DMARC protocol to complete the total picture.

Hi Hector, this thread is no longer productive to the work that this working 
group needs to immediately accomplish.  What you're referring to is more 
properly part of a latter phase/milestone, but first the WG needs to finish 
compiling the actual list of "indirect email flows".

The WG is focused now on compiling this list to avoid issues that arise when 
the problem space is too narrowly defined.  Unfortunately this means you need 
to wait for the WG to catch up to you.  To make sure the WG isn't delayed, I'm 
asking for reviews of the current work:

  http://trac.tools.ietf.org/wg/dmarc/trac/wiki/MilestoneOneWiki

Anything else right now is simply a distraction.

1/2 of the WG Chair,
=- Tim

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

Re: [dmarc-ietf] wiki vs. list?

[Tim Draegen]

Hello, please remember to keep this dialogue respectful.

Feel free to review:

  http://trac.tools.ietf.org/wg/dmarc/trac/wiki/MilestoneOneWiki

...as it forms the basis for meeting the WG's first milestone.

1/2 of this WG's Chair,
=- Tim

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

[dmarc-ietf] progress towards milestone 1

[Tim Draegen]

WG,

During the WG's allotted IETF91 time (Friday November 14th @ 9 AM Hawaii time), 
we’ll need to make a decision as to whether or not we’ve adequately documented 
all known issues between DMARC and indirect email flows.  I don’t think we’re 
quite there yet, but we’re close.

I’ll be spending a lot of time with the Wiki over the next week primarily to 
make sure the WG has an easy-to-reference resource for the next deliverables, 
but secondarily to make sure those folks that are late to the party have 
something they can immediately review.  If anyone would like to dedicate some 
time to this, please contact me directly and we’ll coordinate.

In the week leading up to IETF91, I’ll be chasing down reviewers with the 
intention of showing up at IETF91 with a piece of documentation that is 
comprehensive enough to move on to the next milestone.  In this area I’m not 
looking for perfection… just enough review so that the WG doesn’t get 
side-tracked by, for example, an unexpected new category of indirect email flow.

Hopefully, if everything can be locked down in time, the IETF91 meeting will be 
a review of the collected data, an acknowledgement that we’re ready for the 
next milestone, and a call for volunteers to begin stitching together the next 
deliverable.

1/2 of the WG’s Chair,
=- Tim

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

Re: [dmarc-ietf] wiki vs. list? (was Re: documenting x-original-from usage)

[Tim Draegen]

On Oct 8, 2014, at 3:20 PM, Scott Kitterman  wrote:
>> A bit ahead of the WG's focus.
> 
> We have one?

Ha!  The WG is supposed to be focused on collecting all known issues between 
DMARC and indirect email flows.  Based on the collected set of issues, we'll 
then switch gears and argue the heck out of possible solutions.

=- Tim

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

Re: [dmarc-ietf] wiki vs. list? (was Re: documenting x-original-from usage)

[Tim Draegen]

On Oct 8, 2014, at 1:42 PM, Dave Crocker  wrote:
> Hmmm...
> 
> I find myself unclear about whether the wiki is intended to be an
> alternative to posting one's thoughts, in which case how with the wg see
> them?
> 
> I'd expect the wiki to be a place to capture thoughts/issues/decisions
> after they've been discussed to some level of stability -- note that
> stability doesn't require actual resolution.

You've got it.  Capturing tidbits from the list discussion using the wiki is 
it.  There's not a lot of wiki modification going on, which is why I'm pointing 
folks at it.


> 
> With respect to adding Origina-From, I don't see it at:
> 
>   http://wiki.tools.ietf.org/wg/dmarc/trac/wiki/MilestoneOneWiki
> 
> and don't know where else to look for it...

It's linked off of 
http://wiki.tools.ietf.org/wg/dmarc/trac/wiki/MilestoneTwoWiki
This is the "Milestone 2" wiki, as the topic appeared to be about how people 
are using
headers to convey information to determine "real source".  A bit ahead of the 
WG's focus.

-= Tim


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

Re: [dmarc-ietf] documenting x-original-from usage

[Tim Draegen]

On Oct 3, 2014, at 11:41 PM, Stephen J. Turnbull  wrote:
> Dave Crocker writes:
> 
>> Along an entirely different line of analysis, note that Original-From is
>> merely adding complexity to the 'who was the author of this message'
>> assessment, very possibly creating yet-another security hole.
> 
> Messrs Chairguys,
> 
> Inquiring Minds Question a Point of Order: doesn't this kind of
> comment belong on the wiki page, now that it's been created?
> 
> Feeling-guilty-about-own-too-long-threads-so-really-wanna-know-ly y'rs,

Yes, it does.  I've added it to the wiki, 'cause it would have taken longer to 
ask Dave to do it.

WORDS OF ENCOURAGEMENT FOR THIS WG:

Everybody should feel free to add to the wiki.  If a long discussion thread 
doesn't end up creating wiki content for newcomers, whatever nuggets of wisdom 
are shared will remain buried.  IMO that's no good, 'cause there is deep and 
varied expertise in this WG already, but it's very difficult to get at it (and 
therefore for a newcomer to figure out where their own expertise fits in).

=- Tim

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

Re: [dmarc-ietf] Modeling MLM behavior

[Tim Draegen]

On Oct 6, 2014, at 4:24 PM, Murray S. Kucherawy  wrote:
> On Fri, Oct 3, 2014 at 9:05 AM, Tim Draegen  wrote:
> On Sep 20, 2014, at 7:41 AM, Alessandro Vesely  wrote:
> > IMHO, we should specify a credible MLM model, even if that can be
> > slightly off topic for the WG, in order to maximize its probability of
> > being adopted.  The rest of this message has some notes to this end.
> 
> Can I get some clarification on the intent here?  As worded, this paragraph 
> suggests that we are looking to produce a model for MLMs to follow in a 
> DMARC-aware world.  I was under the impression that (a) this is a 
> non-starter, and (b) we're not chartered to do so.

Sorry to inject confusion and not immediately follow up.

The intention is to have something in place -- the MLM model -- that can be 
used to quickly identify issues that are related to DMARC interoperability with 
any given piece of MLM software.  I read Alessandro's model as a way to 
generically describe MLMs, which would make comparing and contrasting of MLMs a 
lot easier.

IOW, fleshing out a matrix of interoperability issues with respect to MLMs is 
made easier (possible?) if we have a generic way to describe MLM behavior.  
This is not meant to be a robust exercise in crafting the ideal MLM.

If something like this is NOT in place, my concern is that the WG will only 
look at the big MLM packages.  If the WG does not spend time collecting input, 
the WG will not be able to make informed decisions regarding solutions.

=- Tim

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

Re: [dmarc-ietf] documenting x-original-from usage

[Tim Draegen]

On Oct 3, 2014, at 12:38 PM, Dave Crocker  wrote:
> The X-* construct has been deprecated.


Yes.  Let's collect everything around what people have been using 
"X-Original-From:" for as a starting point.  The application of this header in 
different contexts brushes up against what the WG is trying to address.

=- Tim

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

[dmarc-ietf] email orphans - embedded devices

[Tim Draegen]

I've created a wiki page to expand upon an often overlooked source of email -- 
embedded devices.

  http://trac.tools.ietf.org/wg/dmarc/trac/wiki/EmbeddedDevices

These sources of email are often incredibly problematic.  Thanks to John Levine 
for quietly inserting this into the WG's wiki.

I'll be trying to find.. volunteers... from various embedded communities to 
contribute to this page. Feel free to note your own experiences.

1/2 of the WG Chair,
=- Tim

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

[dmarc-ietf] documenting x-original-from usage

[Tim Draegen]

Although a bit forward looking, I've created this page:

  http://trac.tools.ietf.org/wg/dmarc/trac/wiki/XOriginalFrom

..for people to add their smarts of how X-Original-From is being used today.  I 
haven't fleshed it out with content, please feel free to do so!

This page is being linked from the next milestone's wiki page, fwiw:

  http://trac.tools.ietf.org/wg/dmarc/trac/wiki/MilestoneTwoWiki

1/2 of WG Chair,
=- Tim

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

[dmarc-ietf] Modeling MLM behavior

[Tim Draegen]

On Sep 20, 2014, at 7:41 AM, Alessandro Vesely  wrote:
> IMHO, we should specify a credible MLM model, even if that can be
> slightly off topic for the WG, in order to maximize its probability of
> being adopted.  The rest of this message has some notes to this end.


The discussion of interoperability between DMARC and MLMs has become opaque 
enough to warrant taking the time to document the learning.  To make comparing 
and contrasting between MLMs possible, I think the WG needs a model -- just 
like Alessandro proposed -- so that we can all talk about this space with a 
common understanding.  AND, so that others can quickly get up to speed and make 
appropriate contributions.

To this end, I've created:

  http://trac.tools.ietf.org/wg/dmarc/trac/wiki/MailingListModel

..and have asked Alessandro to put his proposal into Wiki form.  Alessandro's 
proposal can be found here:

  http://www.ietf.org/mail-archive/web/dmarc/current/msg01670.html

Everyone is free to help out by working on the page.

1/2 of the WG Chair,
=- Tim

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

[dmarc-ietf] CIVILITY REMINDER - Re: yet more From rewriting, was Additional List-foo Header Field To Help Mitigate Mailing List Damage

[Tim Draegen]

On Sep 17, 2014, at 5:10 AM, John Levine  wrote:
>> I would certainly suggest a thing independently of DMARC (thus "both 
>> technically accurate and real-world-sensible") and, indeed, can't even 
>> claim credit for it: this has come up before in both the DKIM/ADSP 
>> discussion and in the origin of the term "authoring list". I am 
>> surprised to learn that you were not around for those discussions.
> 
> I was.  Lists that rewrite the From: line were a bad idea then, and
> are an equally bad idea now, for reasons that have been discussed to
> death.
> 
> If we're just going to beat dead horses here, we can save a lot of
> time and shut down the WG now.

This is a friendly reminder to keep the discussions civil and respectful.

Everyone is free to summarize previous discussions and contrast them with 
today's context for the benefit of the WG's chartered work.  If prior 
discussions are brought up, please take the time to summarize, contrast with 
today's context, and make relevant to the WG's work.

Last thing - the WG is chartered to perform specific work:

  https://datatracker.ietf.org/wg/dmarc/charter/

..and the WG will continue until this work is done.  Participation is entirely 
voluntary.  I'm asking everyone to please treat the volunteers (including me!) 
with civility and respect.

=- Tim
1 of 2 Chairs of this WG

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

[dmarc-ietf] Milestone 1 wiki updated

[Tim Draegen]

I've gone through and updated the Wiki to fold in items that the list has 
discussed:

  http://trac.tools.ietf.org/wg/dmarc/trac/wiki/MilestoneOneWiki

Please continue to flesh out the existing items and to raise additional items.  
The devil is in the details.

Thanks to Stephen J. Turnbull for taking the first cut at the Wiki.  The 
volunteer editors should be stepping in to fold in additional feedback as it 
develops.

=- Tim

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

Re: [dmarc-ietf] Milestones changed for dmarc WG

[Tim Draegen]

On Aug 31, 2014, at 2:26 AM, Stephen J. Turnbull  wrote:
> My feeling is that the DMARC consortium would appreciate a change of
> wording like the one I proposed, and I'm all for keeping them happy
> and in the club.  If the distinction doesn't matter to others, why
> not?

Hi Stephen, I replied to your suggestion here:

 http://www.ietf.org/mail-archive/web/dmarc/current/msg01577.html

..and based on the rest of the thread, there doesn't appear to be anything to 
do.


As a point of clarification: it is not helpful for this WG to carve out special 
consideration for "the DMARC consortium".  All organizations listed on 
DMARC.ORG have been made aware of this WG's activity, and they've been invited 
to participate directly.

-= Tim

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

Re: [dmarc-ietf] draft-kucherawy-dmarc-base-04 issue

[Tim Draegen]

On Aug 29, 2014, at 11:39 PM, Scott Kitterman  wrote:
> Since this is the WG list, I'm not sure if this is still the right list for 
> issues with the base spec or not, but here goes ...

Right list.  Just to set precedent, any thoughts on this issue will be captured 
in the WG's issue tracker.  Once the WG shifts to considering specification 
changes (next year), we'll bring it up again and fold necessary changes into 
spec.

=- Tim


> The definition of "fo" in Section 5.2, General Record Format, allows both 
> values of "0" and "1" to be specified.  It was suggested to me offlist that 
> this 
> might not be appropriate, so I thought it worth a discussion.
> 
> Does anyone who's implemented "fo" have a problem with both "0" and "1" being 
> specified?  If it is somehow problematic, then the base spec ought to say so.


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

Re: [dmarc-ietf] Milestones changed for dmarc WG

[Tim Draegen]

On Aug 30, 2014, at 9:57 AM, Pete Resnick  wrote:
> We in the WG understand what we mean, and we can certainly be clear about it 
> in the wiki. But I see no need for a change to the milestone text.

Almost had some crosstalk..

Stephen, the wiki is supposed to make this aspect clear, specifically "Phase 
2".  If this isn't clear ("proposed specification changes"), we can make it so.

-= Tim

http://trac.tools.ietf.org/wg/dmarc/trac/wiki

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

[dmarc-ietf] How we'll produce deliverables. And we're starting now!

[Tim Draegen]

The working group's five milestones [1] all involve the production of 
documentation.  To meet each milestone, the working group will follow a simple 
process: Collect ideas/issues, edit into document form, review, and then 
publish (and not necessarily as official IETF documents).

To make sure the WG can focus on generating the best possible output, the 
actual writing/editing of documentation will fall to two editors.  Henrik 
Schack and Tomki Camp will act as these editors for the first milestone, which 
is to catalog all known interoperability issues between DMARC and indirect 
email flows.  The WG Wiki will be used in the development of the document [2].

With that said, the immediate WG topic is to collect all known interoperability 
issues between DMARC and indirect email flows.  Please post your issues, and 
the editors will begin their work.

Tighten your shoelaces,
=- Tim

[1] http://trac.tools.ietf.org/wg/dmarc/trac/roadmap
[2] http://trac.tools.ietf.org/wg/dmarc/trac/wiki/MilestoneOneWiki

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

Re: [dmarc-ietf] Milestones changed for dmarc WG (public suffix exclusion)

[Tim Draegen]

On Aug 29, 2014, at 3:07 PM, Douglas Otis  wrote:
> The charter statement indicates work on a public suffix concept is 
> out-of-scope.  This is fine provided the definition used in the charter is 
> retained:
[snip]
>  Such policy assertions should be a matter handled within the WG as related 
> to organizational domain policy.

Hi Doug.  I'm not Pete but you're writing about the charter's scope and so I'll 
jump in.

Simply put, the public suffix concept is useful beyond what DMARC requires of 
it.  The best that DMARC can do (as a piece of technology) is fully articulate 
1 specific use case for the public suffix concept, and hope that other use 
cases get fleshed out enough so that a viable solution can be crafted by 
something other than this WG.

The closest DMARC comes to discussing policy assertions between organizational 
domain policy and "everything below the organization" shows up in 1) the DMARC 
record discovery mechanism (that is, look at direct domain first and if nothing 
is there then look for a record at the "organizational domain") and 2) the 
DMARC options of "p=" and "sp=".   How number 1 and 2 are used in operation -- 
as it's not exactly clear to the casual reader -- can be captured and explored 
in the operational-facing Usage Guide document.  I hope this describes how the 
WG will tackle what you've brought up.

=- Tim

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

Re: [dmarc-ietf] Milestones changed for dmarc WG

[Tim Draegen]

On Aug 29, 2014, at 2:09 PM, Dave Crocker  wrote:
> I'm also wondering about the implied overlap of work, cased on the close
> proximity of the final milestones.

The final milestones represent parallel work efforts -- and hopefully they're 
different enough from each other that they can progress independently.

One deals with operational best practice, the other with the tech spec.

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

Re: [dmarc-ietf] Milestones changed for dmarc WG

[Tim Draegen]

On Aug 29, 2014, at 2:06 PM, Pete Resnick  wrote:
> Are you OK with the following edits?
> 
> Dec 2014Complete draft on DMARC interop issues + possible methods to 
> address
> Mar 2015Complete draft on DMARC improvements to better support indirect 
> email flows
> May 2015Complete draft on DMARC Usage Guide
> May 2015Complete draft on changes to DMARC base spec
> 
> (That is, separating out the two documents from the May date, and rewording 
> them a bit.)
> 
> If so, I can make the changes as I approve them.

Yes!

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

Re: [dmarc-ietf] Milestones changed for dmarc WG

[Tim Draegen]

On Aug 29, 2014, at 12:50 PM, Pete Resnick  wrote:
> Tim/Ned [Ccing WG]:
> 
> While I think the milestones that appear in the wiki are great for internal 
> WG management (and in fact I think you could even add more of them), I think 
> for the external-facing milestones on the charter page, you should have the 
> more common externally visible milestones like "initial draft of X" or 
> "submission of completed document Y to the IESG", etc.
> 
> That work for you?

Yes it does.  I'll rework the external-facing milestones to perhaps remove some 
confusion.
=- Tim

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

Re: [dmarc-ietf] Start of DMARC WG + proposed milestones

[Tim Draegen]

On Aug 24, 2014, at 10:35 PM, Kurt Andersen  wrote:
> >   Once the milestones discussion has settled..., Ned and myself will create 
> > an outline of topics and work items that, when worked through, should have 
> > the WG arrive at its deliverables.
> >
> > =- Tim
> 
> What about adopting a somewhat more agile, less waterfall strategy?
> 


Kurt, although I don't see this WG as a product development exercise (where 
agile and its bugbear waterfall tend to live), I think you're touching on 
something that should be clarified.

There are a few challenges in play that will make this WG difficult: the email 
community is vast (because the deployment base is almost ubiquitous), email has 
been around for a long time (and there probably isn't an upgrade cycle), and 
the WG is focused on understanding and addressing DMARC's impact on indirect 
email flows (which means we're not likely to hear from people where impact is 
near zero).

Against this backdrop/problem-space, the order of the milestones is important.  
Obviously, the latter milestones are informed by the earlier ones.. BUT, 
there's a nuance in play due to the enormity of the problem space.  The 
milestones will allow the WG to solicit participation from the email community 
for specific topics/work-items without requiring full-time participation for 
the next 9+ months.  This work has to remain accessible.

So, the WG will maintain an "official focus" that will track the milestones to 
allow for wider participation.  That said, work on items that are ahead of the 
official focus (or even behind if something is overlooked and important) is 
most definitely encouraged, because it doesn't make sense to nip constructive 
work in the bud just to follow process.  The only caveat I can think of is that 
topics/work-items will necessarily remain open until the WG officially focuses 
on them (again with the aim of inviting wide participation).

I hope the above is an acceptable compromise between remaining agile with 
respect to work items while keeping a schedule for those of that require an 
explicit time & place to be productive.

=- Tim

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

Re: [dmarc-ietf] Start of DMARC WG + proposed milestones

[Tim Draegen]

On Aug 23, 2014, at 10:34 AM, Miles Fidelman  wrote:
> I did notice the absence of anything related to process.  How are we going to 
> get to a "document (that) captures all known interoperability issue between 
> DMARC and indirect email flows?"  If this were an RFC, there'd be an author 
> or authors identified, maybe a draft to start from.
> 
> At a minimum, it seems like someone might want to generate an initial 
> outline, and set it up as a wiki where folks can start providing input.

Hi Miles, you're right.  There is very little around process today.  Once the 
milestones discussion has settled (as I probably too briefly mentioned to Dave 
Crocker in this thread), Ned and myself will create an outline of topics and 
work items that, when worked through, should have the WG arrive at its 
deliverables.

This outline should give everyone a clear picture and plenty of opportunity to 
volunteer.  !

=- Tim

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

Re: [dmarc-ietf] Start of DMARC WG + proposed milestones

[Tim Draegen]

On Aug 23, 2014, at 12:30 PM, Dave Crocker  wrote:
> On the other hand, a common exercise in a wg organizing bof is to look
> for a show of hands for interesting in specific topics and willingness
> to work on them.
> 
> Perhaps an informal query like that, here, would be useful?

Yes, I'll post such a query once the milestone discussion is wrapped up.  
Working backward from each milestone to identify topics and work items will 
surely reveal plenty of work to go around.

=- Tim

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

Re: [dmarc-ietf] Start of DMARC WG + proposed milestones

[Tim Draegen]

On Aug 21, 2014, at 2:04 AM, Eliot Lear  wrote:
>>- EOY 2014: Deliverable #1 (above document + possible methods to address).
> 
> That seems quite short a period between adoption and approval, and I
> question whether you will get sufficient review at a time when in
> America there is Thanksgiving, and then in December much of the world
> takes two weeks off".  I'd suggest pushing back one month.

Thanks Eliot.  The order of the work is the most important thing.  When the WG 
gets near a milestone and its clear the WG is in the thick of it, then the 
milestone will be pushed back.

=- Tim


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

Re: [dmarc-ietf] [apps-discuss] Start of DMARC WG + proposed milestones

[Tim Draegen]

On Aug 18, 2014, at 11:50 AM, MH Michael Hammer (5304)  wrote:
> Is the DMARC Usage Guide the same as the BCP or is it a different document? 
> If it is a different document, is the BCP going to be one of the milestones 
> for the WG or is it off the table?

They are one and the same.

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

[dmarc-ietf] Start of DMARC WG + proposed milestones

[Tim Draegen]

Hello world of email,

The DMARC WG is getting started [1].  This IETF working group's goal is to 
address interoperability issues with indirect email flows, to document 
operational practices, and to mature the existing DMARC base specification.  If 
you would like to join please visit the DMARC WG [2].

The WG's Wiki page [3] documents the approach the WG will take to produce its 
deliverables.  You can find the roadmap/milestones on the site [4].  For your 
convenience, the proposed milestones are:

- 91st IETF: Document describing interoperability issues with DMARC and 
indirect mail flows.
- EOY 2014: Deliverable #1 (above document + possible methods to address).
- Feb 2015: draft DMARC Usage Guide
- 92nd IETF: Deliverable #2 - Document describing DMARC improvements to 
better support indirect mail flows. 
- May 2015: Deliverable #3 - base spec changes + DMARC Usage Guide

If you have comments on the milestones, please provide them by August 25th.  
Have fun,

=- Tim


[1] http://datatracker.ietf.org/wg/dmarc/charter/
[2] https://www.ietf.org/mailman/listinfo/dmarc
[3] http://trac.tools.ietf.org/wg/dmarc/trac/wiki
[4] http://trac.tools.ietf.org/wg/dmarc/trac/roadmap

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

Re: [dmarc-ietf] Draft DMARC working group charter

[Tim Draegen]

On Jul 1, 2014, at 12:00 PM, Dave Crocker  wrote:
> Otherwise, I think the major question now is whether there is general
> consensus on submitting this draft charter text to the IESG?

Dave, I'm not sure if you're asking, but I think the WG Charter is good enough. 
 Consensus++

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

[dmarc-ietf] Draft DMARC working group charter

[Tim Draegen]

On Jun 23, 2014, at 1:44 AM, Barry Leiba  wrote:
> Let's please stop all the other discussions for now, and say that the
> purpose of the  mailing list is, for now, to discuss
> the charter proposal and converge on a charter for a working group.
> 
> http://trac.tools.ietf.org/wg/appsawg/trac/wiki/DMARC

IMO, the proposed Charter does a good job of recognizing the complexity of the 
topic, which is why it seems to be long.

Two points stick out to me.  One of emphasis and one of clarity.

1. I like the break out of different tracks.  The divide and conquer approach 
would give time and attention to all facets of the work (I don't see any 
missing tracks at a high level).

As a bonus, maybe specific areas of work can be announced in advance so 
that everyone involved knows what to expect.  This would help keep list 
conversations relevant to the focus of the WG, and would also allow people time 
to solicit feedback/participation on specific topics from interested 
communities.

2. "The working group will seek to maintain the viability of stable 
domain-level identifiers in mail.." This is a powerful statement.  I take this 
to mean that the WG won't have to focus on the "Why" of stable domain-level 
identifiers in mail?  If this is the case, I'm suddenly seeing the WG as being 
able to focus on the technical work.

=- Tim


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

Re: [dmarc-ietf] Solution for DMARC disruption of normal email use while still offering its normal protection

[Tim Draegen]

Stephen!  Welcome!  No one said making sausage was pretty.  :-(

On May 29, 2014, at 6:21 AM, Stephen J. Turnbull  wrote:
> Tim Draegen writes:
> 
>> John, you are very difficult to communicate with, maybe because
>> you're easily insulted, even when there is no insult.  I too have
>> been in correspondence with mailing list developers,
> 
> Which ones?

I don't think it would be appropriate to name people, but to a larger point, I 
have to apologize if I come across like a jerk.  There are a lot of people 
trying to deal with DMARC across many forums, and my attempt to imbue a sense 
of breadth and depth was ham fisted.  I live and learn. 

> 
>> and also developers behind businesses that rely on email,
> 
> That's insufficiently precise.  To my mind, there are two kinds (at
> least) of businesses that rely on provision of mailboxes (other use
> cases follow).

I was thinking of businesses that rely on the perfectly acceptable (but now at 
loggerheads with DMARC-based controls) practice of sending on behalf of 
customers.  For example, "stationary" businesses (described towards the end of 
this mail:
http://www.ietf.org/mail-archive/web/dmarc/current/msg00923.html).
There are also businesses that perform "SMTP Cleaning" ala anti-spam filtering, 
plus "SMTP backup" services that people find enough value in to pay for.

My ham-fisted point was that mailing lists are interesting for sure, but the 
scope of email (potentially) impacted by DMARC is bigger, and maybe we should 
think about the space a bit more generically.

> Does DMARC actually impose significant burdens on the "corporate use
> case", contrary to my belief?

I don't personally carve up the email space along corporate vs non-corporate 
lines.  People at corporations communicate via mailing lists.

Before Yahoo and AOL went to p=reject policies, the advice was to keep 
DMARC-reject policies to "transactional" domains. "Transactional" in this 
context mapped to "email that isn't likely to be impacted by things that break 
DMARC like mailing lists"  stuff like account notifications, receipts, not 
people-to-people.

But it turns out that quite a few people create mini mailing lists to map a 
single recipient of a transactional piece of email to multiple recipients... 
like receipts going to bi...@family.org, where the parents and an archive are 
the final recipients.  So, dang.

> Of course there are other use cases of "businesses that rely on
> email".  I understand the "mailing list as user forum" case, and I
> believe Mailman has already implemented a sufficiently broad set of
> measures for business use in this use case.  The tradeoffs aren't
> pleasant, but that's a cost of doing business with Yahoo! and AOL
> users.  A business has the usual set of options (pay the costs, find
> less costly customers, use alternative forum technology, etc).  I
> don't see a real problem here.

>From your mouth to the Internet.God's ear!

> There's also the "on behalf of" content provision use case.  Others
> describe a good remedy in this thread, but I would like to point out
> that such providers may publish "p=reject" to good effect, as an
> instance of the "corporate use case".
> 
> But my knowledge of "business use" is quite limited.  Are there other
> "business activities relying on email" such that DMARC imposes
> burdens?  Are those burdens specific to "p=reject", or more general?
> 
> (If this is all well-known, please point me to a reference where I can
> book up without disturbing the Councils of the Wise.)

One giant problem that ISPs face is that they have large numbers of customers 
that send email through their infrastructure but for domains that are not 
related to the ISP.  Imagine a residential network providers with lots of 
customers that configured their email clients 20 years ago.  It's largely 
worked up until now.  Is the ISP supposed to contact each customer and get them 
to use the correct outbound SMTP servers?  What is the right thing to 
communicate?

Council of the Wise?!  I always thought the IETF was a bunch of people hanging 
off the edge of the world, getting together every once in a while to maybe 
allow an accidental shared piece of understanding to be written down.

> 
>> and also a slew of decision makers... and they're all trying to
>> understand how they can fix things without going backwards.
> 
> IMO, they're wasting their time.
> 
> Email service *must* deteriorate in the presence of users who send
> messages from "p=reject" domains, unless those domains are draconian
> in enforcing direct transmission to final destinations that observe

Re: [dmarc-ietf] Non-solution for DMARC disruption of normal email use while still offering its normal protection

[Tim Draegen]

On May 29, 2014, at 3:05 AM, John R Levine  wrote:
> Really, that makes no difference.  I don't want Yahoo or anyone else to pay 
> us to screw up our mail software to work around them -- I want them to spend 
> their money to fix things so we don't have to.

Yes, I get it, I guess in my own jaded way I don't think there is any amount of 
money that Yahoo and AOL can spend that will fix things (because email isn't 
owned by Yahoo or AOL).  BUT, if Yahoo or AOL is willing to experiment, let 
that experiment be me!

I replied to Doug earlier (not yet in archive), and hashed out my own thinking 
around how much domain owners can do vs. how to address 
"legitimate-but-unauthorizable" email.

TLDR summary: addressing "legitimate-but-unauthorizable" mail is my answer to 
Scott Kitterman's question: "How do we define the scope of work for this list?".


> 
> Yahoo, in their own blog, estimates there are 30,000 mail systems that they 
> have damaged by their DMARC actions.  I would be surprised if there were more 
> than a few hundred mail systems acting on DMARC policies, although some of 
> those are very, very large. Is it that hard to understand why someone might 
> think it was unreasonable to demand that the 30,000 make changes of no 
> benefit to themselves, rather than the few hundred fix their buggy fussp?

I don't think there is/was a way for Yahoo to fix the estimated few hundred 
mail systems acting on DMARC policies, especially since most are not controlled 
by Yahoo.  Maybe they could have published a list of 30,000 mail systems that 
are white-listed, but wouldn't that just be a publication of 30,000 holes to 
exploit?

The absolute most work I could imagine Yahoo and AOL having done would have 
been to analyze and publish a series of articles/guidance on how impacted email 
can be fixed, complete with accessible patches to all known mailing systems.  
THEN, give the entire internet enough time to apply said patches.  This is my 
unicorn.

For the next 10 years, I'm going to attempt to recreate this unicorn.

> 
> The 30K estimate is probably low, since there are likely many small mail 
> systems they aren't aware of but that they are damaging. For example, 
> yesterday a middle school teacher who found my old Dummmies web site wrote to 
> me out of the blue to say that his web form that lets students and parents 
> send mail to him stopped working for AOL and Yahoo addresses, which just 
> disappear.  It took about two seconds to figure out what was wrong when he 
> told me that his script sends mail to his Gmail account.  I told him what was 
> wrong, and he did a hack that sticks in a fake From: address, so the mail 
> gets through but now his script works worse since he can't write back without 
> extra effort.  If he hadn't written to me, he'd probably never have figured 
> out what was wrong.  These are real people who are really hurt by the two 
> providers' actions.

In a similar vein, there are a fair number of businesses that do stuff like 
encapsulate their customer mail with bling (fancy headers, pictures, footers w/ 
disclaimers... "stationary"), and they're having to figure out how to maintain 
their service when sending on behalf of clients with Yahoo and AOL addresses.  

What is missing is "how am I supposed to do this right"?  I'm not being glib, 
there's a real vacuum due to email being what it is, and it's a vacuum that I 
personally don't think corporations can/should fill.

-= Tim

> 
> Regards,
> John Levine, jo...@taugh.com, Taughannock Networks, Trumansburg NY
> Please consider the environment before reading this e-mail.
> 
> PS: Here endeth the rant.

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

Re: [dmarc-ietf] Solution for DMARC disruption of normal email use while still offering its normal protection

[Tim Draegen]

On May 28, 2014, at 8:48 PM, Douglas Otis  wrote:
> Dear Tim,
> 
> All that is needed is a few bandaids?

Hi Doug, I don't see the problem space as allowing bandaid approaches.  The 
widespread ability to build controls on top of stable domain level identifiers 
is relatively new.  In my view, people that want to use these controls are 
stuck in one of two ways:

1. They're trying to modify how their email is structured so that controls can 
safely be put into place, and there is some sort of relationship that allows 
change to happen.  Franck Martin wrote previously about this here:
http://www.ietf.org/mail-archive/web/dmarc/current/msg00878.html

2. They're trying to address "legitimate-but-unauthorizable" email.  In this 
bucket I'd put everything that is mostly beyond the ability for individual 
domain owners to change: mailing lists, forward-to-friend, services that send 
on behalf of users.  Scott Kitterman wrote about this and asked about the scope 
of IETF work in this bucket:
http://www.ietf.org/mail-archive/web/dmarc/current/msg00872.html

Pain due to inaccurate deployment of controls is the domain owner's problem (#1 
above).  There (should be!) plenty of feedback available for domain owners to 
recognize their own problems.

Pain due to everything else (#2 above) is something domain owners can't expect 
to solve on their own.  It's in this area that "bandaids" might work in the 
short term (like publishing lists of exceptions), but long term I'd personally 
prefer not to see a codified model of exceptions.

I think it would be better to specify how impacted email in bucket #2 can be 
dealt with, but not with a goal of preserving all existing email use cases.  
IMO a better goal would be to specify how specific categories of email should 
be presented.  For example, codify how mailing lists go about their business 
(maybe: adhere to relevant RFCs + DKIM sign with ML's domain + perform OAR-like 
checks).  A different example: analyze the use of "Reply-to:", determine what 
is preferable behavior, and codify what should be expected.  The resulting 
specifications would at least tell developers (across the spectrum from MTA 
through MUA) what they need to do to interoperate.


> 
> The motivation behind TPA-Label was to ensure both quick and efficient 
> methods to offer necessary feedback to receivers.  DMARC already expects 
> receivers to offer failure feedback to DMARC domains.  Unfortunately, once 
> the DMARC domain has decided which third-parties need to be granted 
> exceptions, there is no way to do so.   It seems dangerous to suggest this 
> can be hard-coded in the form of informal lists indicating which DMARC 
> domains should be ignored.

I think I understand the motivation.  I guess I'm in the horrible position of 
viewing TPA-Label as a bandaid, given my own view of the scope and amount of 
work involved in making email suck less.  I don't mean to disparage TPA-Label 
-- I just mean that given a finite amount of focus and fuel, I'd prefer to work 
out what I wrote about above: "specifying how impacted email in bucket #2 can 
be dealt with".

> 
> In the case of Yahoo, there is a real issue they are attempting to mitigate.  
> It would be nice to have a solution able to deal with massively compromised 
> user accounts, as ugly as that is.  This is an issue that is not going away 
> any time soon.  The issue is much worse in China, for example.  Please don't 
> decide being helpful in such situations is simply too hard.  Is it really 
> better to create lists about which domains get ignored? It seems this quickly 
> degrades DMARC's initial intent, which was to offer results receivers felt 
> safe to act on.  Is this still a worthy goal?

One facet of the problem that Yahoo & AOL are addressing via DMARC-based 
controls goes beyond "compromised user accounts".  A malware-infected PC's 
local address book gets scraped, and the infected PC emits spam/malware that 
spoofs the owner of the PC's email address (because fraud appearing to be from 
a known friend/colleague is pretty effective fraud).  This fraud does not flow 
through Yahoo or AOL.

I hope the above shows that the size and scope of difficult problems is not 
something I'm looking to work around.  IMO bandaids are exception-lists and 
mechanisms like TPA-Label, and the difficult (but necessary) work remains in 
proposing, researching, specifying, implementing, and advocating for how well 
established mailing practices can interoperate in an email environment where 
stable domain-level identifiers are the norm.

-= Tim

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

Re: [dmarc-ietf] Solution for DMARC disruption of normal email use while still offering its normal protection

[Tim Draegen]

On May 28, 2014, at 12:37 PM, John Levine  wrote:
>> Its not clear to me that gmail.com needs to tell another service to trust
>> the OAR from a given third party, the choice to trust that service could
>> easily be up to the receiving service.
> 
> Good point.  That's why I keep saying that one or a few shared
> DMARC-bypass whitelists would work a lot better than anything
> per-sender.  The set of senders where it makes sense to skip DMARC
> checks for Yahoo or AOL or Gmail addresses are likely to be the same.

Doug,

I read through the spec, and it is clear a lot of work went into it.  I think I 
echo Brandon and John's above opinions.

>From my PoV, there exists an immense pile of work to get through before the 
>draft under discussion becomes a solution.  Aside from support, tooling, 
>getting senders to deploy accurately and getting receivers to perform 
>additional checks.. what is missing is the justification for the additional 
>work.

DMARC is a tradeoff between keeping things as simple as possible (as 
unnecessary complexity acts as a giant barrier to adoption), building on 
existing technologies (as new code/libraries in the world of email means 
tacking on additional calendar years), and solving a problem that hurts enough 
to warrant doing anything at all.

I don't believe TPA-Label hits the mark between "solving a big hurt" and 
"simple".  IOW, it's too complicated for the amount of pain it would resolve.  
Just my opinion, take care,
=- Tim

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

[dmarc-ietf] spec missing ABNF for "fo" tag

[Tim Draegen]

Hi,

Section 5.3. of the DMARC spec is missing ABNF for the "fo" tag.

The necessary changes could be (I'm no ABNF master):

Adding to "dmarc-record" definition:
[dmarc-sep dmarc-fopt]

And adding the actual definition:
dmarc-fopt= ( "0" / "1" / "d" / "s" )
dmarc-fo  = "fo" *WSP "=" *WSP
dmarc-fopt *(*WSP ":" *WSP dmarc-fopt)

Hope this helps,

=- Tim


PS. Thanks to as astute dmarcian.com user for pointing this out!

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

Re: [dmarc-ietf] ADSP to Historic?

[Tim Draegen]

+1   Bonus pluses for inserting some forward reference so that naive ADSP 
deployers know where to go next.

=- Tim


On Sep 11, 2013, at 7:03 PM, Dave Crocker  wrote:

> 
> just looking for initial reactions, to judge whether to make the formal 
> request.  a +/- 1 certainly qualifies.
___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc