[dmarc-ietf] Treewalk causing changes

[Elizabeth Zwicky]

I haven’t done extensive research but here is a live example where treewalk will cause a result change. From: is in the domain Ret.bmcc.cuny.edu which has no DMARC record. _dmarc.bmcc.cuny.edu.300INTXT"v=DMARC1; p=quarantine; fo=1; rua=mailto:dmarc_...@emaildefense.proofpoint.com; ruf=mailto:dmarc_...@emaildefense.proofpoint.com"_dmarc.cuny.edu.3325INTXT"v=DMARC1;" "p=none;" "rua=mailto:dmarc_...@emaildefense.proofpoint.com,mailto:post.mas...@cuny.edu;" "ruf=mailto:dmarc_...@emaildefense.proofpoint.com,mailto:post.mas...@cuny.edu;" "fo=1"Elizabeth Zwicky___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

Re: [dmarc-ietf] What bad stuff can a broken DMARC record cause?

[Elizabeth Zwicky]

Lots of people have wildcard TXT records which mean that if you look up a DMARC 
record you get an SPF record. They get the delivery they’d get with no DMARC 
record on the systems I know about and it doesn’t seem to annoy them enough to 
make them stop, which is reasonable evidence it doesn’t make a difference they 
can perceive elsewhere. 

Elizabeth 

> On Apr 24, 2022, at 11:38 AM, John R Levine  wrote:
> 
> Someone I know asked me what sort of bad things could happen if one 
> published a broken DMARC record.  Obviously, if your record is bad people 
> won't follow your policies and you won't get your reports, but anything else? 
>  Have you ever heard of MTAs burping on a bad DMARC record?
> 
> I've looked at the C OpenDMARC and perl Mail::DMARC libraries and they both 
> seem pretty sturdy: fetch a TXT record and if they find one, look for the 
> tags they want and ignore everything else.
> 
> As an experiment, I added 32K of junk to the _dmarc.johnlevine.com TXT record 
> and as far as I can tell, it's made no difference.  I still get the same 
> reports saying the same things.  DNS libraries need to use TCP to fetch it 
> but they all seem able to do that.
> 
> Regards,
> John Levine, jo...@taugh.com, Taughannock Networks, Trumansburg NY
> Please consider the environment before reading this e-mail. https://jl.ly
> 
> ___
> dmarc mailing list
> dmarc@ietf.org
> https://www.ietf.org/mailman/listinfo/dmarc

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

Re: [dmarc-ietf] Tree walk is not a heuristic, was screwed up

[Elizabeth Zwicky]

> On Jan 25, 2022, at 10:35 AM, John R Levine  wrote:
> 
> Do we have any stats on how often real mail depends on sibling alignment? If 
> nobody actually uses it, the spec would be simpler if we could take it out.

Stats are tricky, but here are some senders using sibling alignment like
From domain: samedaycity.FedEx.com
DKIM domain: freight.FedEx.com
SPF domain: nds.FedEx.com

Most of these don’t do it for all mail, but account and billing related mail or 
customer support mail are particularly likely to use it
FedEx, obviously
Uber
Intuit
NextDoor outside the US
Taco Bell
McGill university
Lots of healthcare billing using the Cedar platform
Atlassian
Alignable.com which tickles my sense of irony
Cmdlr.com which sends mail for a variety of car dealerships 

These are cherry-picked from a few minutes of incoming mail. So in practice, 
turning it off would cause significant disruption. 

Elizabeth 

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

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

Re: [dmarc-ietf] spec nit - which DKIM to report

[Elizabeth Zwicky]

The problem with that language is that
>  o  The identifier evaluated by DKIM and the DKIM result, if any

is genuinely unclear. Often there are multiple identifiers. Does this mean I 
can pick any one of them? (That does not actually provide sufficient 
interoperability.) If there’s a specific one I should pick, which is it?

Elizabeth 


On Jun 21, 2019, at 12:11 PM, John R Levine  wrote:

>> I believe they MUST contain any aligned DKIM signature regardless of 
>> validity and SHOULD  contain an entry for each domain, selector, result 
>> triple.
> 
> RFC 7489 says:
> 
>   The report SHOULD include the following data:
> 
>   o  The DMARC policy discovered and applied, if any
> 
>   o  The selected message disposition
> 
>   o  The identifier evaluated by SPF and the SPF result, if any
> 
>   o  The identifier evaluated by DKIM and the DKIM result, if any
> 
>   o  For both DKIM and SPF, an indication of whether the identifier was
>  in alignment
> 
> (and a bunch of other stuff)
> 
> I don't see any basis to change this, since as long as the report's format 
> and syntax are correct, it'll interoperate.  It may not have all the hints 
> the report's recipient would like, but life is like that.
> 
> R's,
> John
___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

Re: [dmarc-ietf] spec nit - which DKIM to report

[Elizabeth Zwicky]

I believe they MUST contain any aligned DKIM signature regardless of validity 
and SHOULD  contain an entry for each domain, selector, result triple. 

Elizabeth 

> On Jun 21, 2019, at 11:46 AM, John Levine  wrote:
> 
> In article <7cd366d2-ab8d-cce8-67ff-59b79183c...@tomki.com> you write:
>> As mentioned by Elizabeth recently:  (Elizabeth please chime in if this 
>> doesn't capture your meaning)
>> 
>> the spec does not define *which* DKIM signature should be reported in 
>> the DMARC RUA created by a receiver.  The proposed resolution to this is 
>> that if the receiver does not provide the complete set of DKIM 
>> signatures found, they should provide (in order of preference)
>> 1. a signature which passed DKIM in strict alignment with the From: 
>> header domain
>> 2. a signature which passed DKIM in relaxed alignment with the From: 
>> header domain
>> 3. some other signature that passed DKIM
>> 4. some other signature that didn't pass DKIM
> 
> This seeems overcomplex.  How about saying the reports SHOULD include
> all valid DKIM reports.  If they can't, they can't, and I don't see
> any benefit in offering advice on how not to comply.
> 
> 
> 
> ___
> dmarc mailing list
> dmarc@ietf.org
> https://www.ietf.org/mailman/listinfo/dmarc

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

Re: [dmarc-ietf] Debugging and preventing DKIM failures- suggestion

[Elizabeth Zwicky]

RFC 7960 has an extensive discussion of mail flows that modify mail (as well as 
other cases that are problematic for DMARC). Mailing lists are not the only 
case, and, as John has pointed out, reformatting and part stripping are things 
that happen in mail flows. 

Elizabeth 

> On May 31, 2019, at 8:02 AM, Hector Santos 
>  wrote:
> 
>> On 5/31/2019 6:59 AM, Douglas E. Foster wrote:
>> 
>> DKIM was supposed to provide sender authentication when SPF was
>> invalidated by forwarding, so DMARC said that the two techniques
>> should be evaluated together.
> 
> Unfortunately, DMARC did not have a policy that offered that output.
> 
>  SPF >> FAIL
>  DMARC >> PASS?
> 
> Overall, DMARC failed to cover all the possible scenarios of mixed signatures.
> 
> To cover all aspects, the DKIM POLICY model has to offer 3rd party signature 
> conditions.   In the DSAP proposal, it highlighted this as the broader 
> possible options:
> 
>https://tools.ietf.org/html/draft-santos-dkim-dsap-00#section-4.2
> 
>+-+
>| op= | 3p=| Domain Policy Semantics  |
>|=|
>| empty   | empty  | No mail expected |
>|-|
>| never   | never  | No signing expected  |
>| never   | always | Only 3P signing expected |
>| never   | optional   | Only 3P signing optional |
>|-|
>| always  | never  | OP signature expected|
>| always  | always | Both parties expected|
>| always  | optional   | OP expected, 3P may sign |
>|-|
>| optional| never  | Only OP signing expected |
>| optional| always | OP expected, 3P expected |
>| optional| optional   | Both parties may sign.   |
>+-+
> 
> That covered all possible combinations.
> 
> We actually wrote an IETF functional spec regarding Sender Signing Policies:
> 
>   rfc5016 Requirements for a DKIM Signing Practices Protocol
>   https://tools.ietf.org/html/rfc5016
> 
>   Abstract
> 
>   DomainKeys Identified Mail (DKIM) provides a cryptographic mechanism
>   for domains to assert responsibility for the messages they handle.  A
>   related mechanism will allow an administrator to publish various
>   statements about their DKIM signing practices.  This document defines
>   requirements for this mechanism, distinguishing between those that
>   must be satisfied (MUST), and those that are highly desirable
>   (SHOULD).
> 
> 
> But then something happen as this document was being completed -- list 
> administrators got scared that DKIM Policy was gaining tractions and stepping 
> into their market toes.  After all, we had "30 years" of legacy list 
> operations, we did not want DKIM Policy interfering with the broad range of 
> established list distribution operations. So this RFC5016 "Blocker" was 
> written at the last minute to preempt it from happening:
> 
>  Section 5.3, Item 10
>  https://tools.ietf.org/html/rfc5016#section-5.3
> 
>   10. SSP MUST NOT provide a mechanism that impugns the existence of
>   non-first party signatures in a message.  A corollary of this
>   requirement is that the protocol MUST NOT link practices of first
>   party signers with the practices of third party signers.
> 
> INFORMATIVE NOTE: the main thrust of this requirement is that
> practices should only be published for that which the publisher
> has control, and should not meddle in what is ultimately the
> local policy of the receiver.
> 
> 
> That was basically, a "Don't step on my turf!!" requirement. It also meant 
> "Local Policy Always Prevail" regardless of what a Domain published which is 
> always the case anyway. Does not need to be stated.  But overall, this is 
> what help demote SSP, ADSP, ATPS and DKIM policy in general.  ADSP was 
> abandoned.
> 
> But no one can kill a good idea,  the proof of concept was too powerful, 
> hence it returned as DMARC but as an informational status document to avoid 
> the IETF mch higher review process.
> 
> I have no idea how a high overhead, complex ARC will resolve this problem 
> unless
> it comes with a 3rd party signature concept with an extended DMARC "arc=y" 
> tag:
> 
>  arc=y  If the 1st party signature failed, then authorize the XYZ
> domains using ARC seals to promote a failure to a pass.
> 
> How would you specify the 'authorization" of XYZ domains and do so at scale?
> 
> -- 
> HLS
> 
> 
> ___

Re: [dmarc-ietf] Spam Filtering Product Guidelines?

[Elizabeth Zwicky]

I’m not sure you realize that spam authenticates at a higher rate than good 
mail. This isn’t a bad thing — it helps in blocking — but it means that 
authentication is nearly orthogonal to spam filtering in large systems. 

Elizabeth 

> On Mar 22, 2019, at 8:10 AM, Douglas E. Foster 
>  wrote:
> 
> Based on my frustration with observed product offerings, it feels like no one 
> has articulated a reference model of how spam filters should operate -- 
> either that, or the vendors are just ignoring such work.
>  
> The SPF / DKIM / DMARC standards define what senders should do, but I don't 
> think it says much anything about what the receiving system should do to 
> resolve ambiguity when these features are not fully implemented by the 
> sender..
>  
> Does this group know of prior work to define such a reference model?
>  
> Doug Foster
>  
>  
> ___
> dmarc mailing list
> dmarc@ietf.org
> https://www.ietf.org/mailman/listinfo/dmarc
___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

Re: [dmarc-ietf] Lenient DKIM (new Internet Draft)

[Elizabeth Zwicky]

http://www.usablesecurity.org/emperor/

Is the most classic paper on the complete uselessness of icons. You’ll note 
that browsers have changed to putting up intrusive pages with unobtrusive ways 
to continue, among other options, instead of showing broken lock icons. 

Elizabeth 

zwi...@otoh.org

> On Sep 28, 2017, at 11:22 PM, Rick van Rein  wrote:
> 
> Hi,
> 
>> Also, among what you're talking about, I think the 7/8/base64 stuff
>> would be covered by his MIME canonicalization.
> 
> Since most MIME content is binary, it would be helpfulto canonicalise 
> individual body parts to their binary/pristine form.  My current
> thinking is that even message/* is binary, and I can think of reasons
> why message/rfc822 should not be mangled in transit, but I'm not sure if
> this is realistic.
> 
> Where MIME content is text/*, I had to learn more about i18n.  Unicode
> was made to solve these riddles, by offering a place to all the
> characters in the world [but not their renderings].  For characters with
> more than one code, Unicode has the notion of canonical equivalence. 
> And where characters may be decomposed into sequences, it has a more
> lenient equivalence notion of compatibility.  The former should be no
> issue for DKIM, the latter may be.  Defining equivalence through
> compatibility works for human texts but may be dangerous for accurate
> content like program fragments and URIs, except that the common
> limitation of these uses to ASCII solves these dangers.  The stringprep
> profiles, including SASLprep which looks very email-suitable, would be
> able to handle all this.  Software support already exists, of course.
> 
> Finally, the nested nature of MIME content allows the recognition of
> failures.  All that needs to be done is add a DKIM-Signature to the body
> parts, and have a mechanism for describing their compositions in a
> change-detectable manner (and sign for that mechanism too).
> 
>> Although I've seen web proxies or clients which resize photos, I don't
>> think I've ever seen an MTA do it... which doesn't mean they couldn't,
>> but I'm not sure it's a use case we have to try and handle.
> 
> Anything of this kind would know that delivery is to a particular class
> of MUA, so it would be near the recipient, where trust has a different
> organisation.
> 
> -Rick
> 
> ___
> dmarc mailing list
> dmarc@ietf.org
> https://www.ietf.org/mailman/listinfo/dmarc
___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

Re: [dmarc-ietf] [dmarc-discuss] exegesis: pass and fail together

[Elizabeth Zwicky]

Tomki pointed out that I am completely wrong about selectors and lots of people 
report them. I should have checked. 

Elizabeth 

zwi...@otoh.org

> On Jul 7, 2016, at 11:38 AM, Steven M Jones  wrote:
> 
> I'm quoting the following response in a thread from the
> dmarc-disc...@dmarc.org mailing list, because I think it identifies work
> items or at least questions this WG may want to address. If this is
> already captured somewhere, my apologies.
> 
> Here's the original thread:
> 
> http://lists.dmarc.org/pipermail/dmarc-discuss/2016-July/003546.html
> 
> 
> Summary: How should DMARC aggregate reports reflect messages with
> multiple DKIM results? And should DKIM selectors be included in DMARC
> aggregate reports?
> 
> 
>> On 07/07/2016 09:16, Elizabeth Zwicky via dmarc-discuss wrote:
>> 
>> And yes, it's entirely possible for a message to have 2 or more DKIM
>> signatures, including signatures for the same domain with different
>> results. As long as there exists a DKIM signature that is aligned and
>> passes, the DMARC DKIM result is pass. (As I recall, the spec is unclear
>> about what you do if there are multiple DKIM results. That should
>> probably be fixed and it would be nice if we allowed the selector to be
>> reported as well.)
> 
> AND:
> 
>> On 07/07/2016 09:53, Elizabeth Zwicky via dmarc-discuss wrote:
>> 
>> I meant to say that the spec is unclear about what you do about
>> **reporting** multiple DKIM results. It's perfectly clear on how to
>> evaluate them.
> 
> ___
> dmarc mailing list
> dmarc@ietf.org
> https://www.ietf.org/mailman/listinfo/dmarc

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

Re: [dmarc-ietf] SPFAuthResultType unbounded

[Elizabeth Zwicky]

Rows are defined by IP; if the same IP uses multiple MAILFROM and SPF is 
bounded what is the reporter supposed to do? Duplicate rows? 

Limiting SPF changes the row key in bad ways. (Unless all senders are 
well-behaved in ways they are not required to be.)

Elizabeth

zwi...@otoh.org

> On Mar 15, 2016, at 4:10 PM, Franck Martin  wrote:
> 
> 
> 
> 
> 
> 
> From: "Tomki" 
> To: "dmarc" 
> Sent: Tuesday, March 15, 2016 3:27:15 PM
> Subject: [dmarc-ietf] SPFAuthResultType unbounded
> 
> Does it make sense that SPFAuthResultType element counts are allowed to be 
> unbounded?
> I would think that it should be a maximum of 2, and then only if the scope is 
> indicated (helo/mfrom)
> 
> from https://tools.ietf.org/html/rfc7489
> 
>
>  
>
>  minOccurs="0" maxOccurs="unbounded"/>
>
>maxOccurs="unbounded"/>
>  
>
> 
> 
> Makes sense, does it matter?
> ___
> dmarc mailing list
> dmarc@ietf.org
> https://www.ietf.org/mailman/listinfo/dmarc
___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

Re: [dmarc-ietf] Indirect Mail Flows

[Elizabeth Zwicky]

By my calculation, purely indirect mail -- mail that never authenticated -- is 
a more frequent problem than mail that was broken along the way. 

If I take a day's worth of data for a couple of end-user domains at p=reject 
and average them together, and the same for p=none, I get this table:


DMARC passDMARC fail
  DKIM brokenDKIM absent
p=reject95.32%0.27%4.41%
p=none  30.88%1.02%68.10%


Much of the absent DKIM, regardless of policy, is horrible mail you wouldn't 
want to deliver. But even so, there's more good mail in that pile than in the 
broken DKIM pile.

But you should notice that the ratios are also starkly different for p=reject 
and p=none; there's about 4 times as much broken DKIM mail at p=none as there 
is at p=reject. There's more than 15 times as much absent DKIM mail (and yes, 
the p=none domains I average do consistently sign their outbound). So, in 
practice, it looks like the absent-DKIM mail is faster to change than the 
broken-DKIM mail. 


I think both problems need attention. The broken-authentication problem is 
small, but there's no current solution to it that preserves desired semantics, 
and the places it happens are important. 


The never-authenticated problem is not going to be solved by the same 
solutions, it also affects good mail, and it also involves semantic changes or 
significant workarounds. In general, the workarounds are more available, 
because the good never-authenticated mail is strongly dominated by commercial 
entities; that opens a range of solutions that are less available for many 
broken-authentication cases. In practice, Intuit's purely third-party mail was 
not affected in the long term, but was interrupted for a few days. 

Elizabeth Zwicky






On Friday, November 14, 2014 9:52 AM, "Silberman, Sam" 
 wrote:




In anticipation of today's DMARC WG meeting, I want to highlight one of
the many important use cases.  Specifically:

Use of "unrelated" outbound SMTP servers
Commercial email using free email address
Newspaper Sites
Reference wiki:  
https://tools.ietf.org/wg/dmarc/trac/wiki/MilestoneOneWiki


Past discussion around these use cases assume the email author has control
of the domain they send email from.
While it may be true for the world's digital elite (i.e. us),  it's not
true for everyone.
There are billion(s) of people who use "free" or very low cost hosting
services to provide email.
For many people, switching email providers is hard (or not an option).
If their mail bounces,  they simply don't have the context to decipher
the difference between "mailbox non-existent" and "DMARC policy reject due
to non-alignment"

Most of the world does not have control over their sending domain.

Previous posts have suggested this is a small problem. I respectfully
disagree.  We need to be focusing on # of users impacted, not percentage
of mail bounced.

Take the following example:  My local PTO (Parent Teacher Organization).

They are a volunteer non-profit.
They have no time or expertise to deal with technical things like email
setup.
They can't ask the local school board for email mailbox (local policy,
bureaucracy , etc).

They have no $$, so they use a free mail service (
p...@dmarc-protected-mailservice.com)

When their mail provider switched to p=reject
They no longer can email some parents directly who used forwards
They no longer can reliably send emails via a 3rd party service provider
(ESP)
They no longer can reliably send update to community mailing list servers


IMO, this is not the 1% use case. It's bigger, much bigger.

I don't claim to have all the answers.
Telling user like this one to change mail providers solves nothing in the
long term. 
DKIM Forward signatures do have promise and solves some of the issues I've
listed above.

Ultimately, solving DMARC indirect flows for this user will get us very
close to solving indirect flows over the rest of the world.


-Sam




___
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] Indirect email flows

[Elizabeth Zwicky]

OK, so I've dived into Yahoo's incoming metadata to look at what fails DMARC 
and why. Conclusion 1: I cannot automatically tell the cases apart with any 
accuracy. Hand coding them is so time-consuming as to be beyond my ability to 
do at scale.
So, not many numbers, but I have developed some very educated opinions, which 
unfortunately take a small novel to explain.
First, transactional domains tend to have some mail that fails DMARC because of 
forwarding. The highest estimate of that I've seen is about 1.5% (that's not 
data I ran); on the domains I've looked at so far I saw rates well below 0.1%. 
Still, that's people not getting their mail. For transactional mail, this is a 
strong majority forwarding (as in I send mail to a...@b.com and it delivers to 
a...@c.com), and it's dominated by educational institutions forwarding to their 
students/alumni, followed by hosting services and ISPs. The reasons for the 
forwarding breaking the signatures clearly vary; there are popular mail systems 
that, for instance, re-mime-encode bodies, or add signature files of various 
sorts, ranging from notifications that the message has been virus scanned to 
ads for the ISP forwarding the mail. Re-encoding things can result in 
intermittent breakage, where some forwarding works (because the forwarder 
doesn't feel the need to fix it) and other messages don't. A minority is not 
straightforward, my old address routes to my new one, forwarding, but are 
services that are specialized to handling mail -- third party spam filtering or 
mail classification products that then redeliver mail. They don't make up a big 
percentage of the cases but they are notable as cases that presumably would be 
able to change their handling if we provided them with options.
Then we get to end-user domains. Although I've heard from corporate domains 
where DMARC breakage is actually lower for the humans than the transactional 
mail, for the big mailbox holders, as far as I can tell, the expected ratios 
hold; more mail fails for end-users than for transactional mail. How much more? 
That gets interesting.
For the domains at p=reject, the mail that arrives with an aligned DKIM 
signature still on it, but not working -- which is the common case for both 
forwarding and mailing lists -- is significantly under 1%. For the domains at 
p=none, that comes closer to 2%. That difference is partly in mailing lists, 
but, sadly, a noticeable amount of the difference between p=reject and p=none 
domains when it comes to the mailing list mail is spam from a few, mostly 
commercial, mailing list providers. It is clear that a number of valid, happy 
mailing lists you might like have chosen to move subscribers from p=reject to 
p=none providers, with mixed success; the high volume ones I've checked still 
have p=reject posters, at low rates. It is also clear that a lot of educational 
institutions *both* run popular, DKIM-breaking forwarders *and* run popular, 
DKIM-breaking mailing lists (and, unsurprisingly, have alumni who go through 
both at once), which is one way that these things rapidly become intractable 
for automated processing. 
For everybody, way more mail shows up with no aligned DKIM signature on it than 
with a broken aligned DKIM signature on it, and no noticeable amount of that 
mail had a DKIM signature stripped off. In fact, for every domain I looked at, 
the single largest cause of DMARC fail is purely forged mail, mostly spam. The 
rate of messages with no aligned DKIM signature ranged from 88% (for a mailbox 
domain with p=none) to 2% (for a transactional domain with p=reject). For 
transactional domains, that mail is not readily distinguishable from pure 
trash. There must be a DKIM-stripping forward out there somewhere, but I 
haven't found it. For end-user domains, once you ignore forged spam, the major 
volume contributors are hosting sites, but again, the use-cases are mixed. The 
highest volume from hosting sites is spam. The next highest is email to site 
owners "From:" themselves. There are a lot of people out there not getting mail 
from really frequent cron jobs. Then we get bulletin boards and blog software 
letting you know somebody has responded to your comment, and e-commerce 
solutions letting you know that somebody wants to order something -- all of 
that shows up in one big jumble from the hosting providers. 
Next we get "parental control" software and other monitoring uses that send 
From: and To: the same address and are verbose. And large service providers for 
small businesses.
After that, it's the land of a million different indirect uses. More e-commerce 
sites. The people who send you happy birthday messages from your dentist, who 
uses a third-party account. Or your tee-time from your golf course, ditto. Or 
your tanning bed schedule, because there's a service out there that does 
nothing but email handling for tanning salons. Printers. Security equipment. A 
surprising number of government agencies, including

Re: [dmarc-ietf] Indirect mail flows

[Elizabeth Zwicky]

Also these get chained together -- think of the person who subscribes to a 
mailing list from a university email address that then ends up being forwarded.
Another big, difficult case is people sending mail via an ISP; you have cable 
Internet at home, you want to send mail via SMTP, you don't want to use 
"u...@ispmail.com", but you are forced through the ISPs SMTP server. 
We are seeing less "mail to a friend" (where the mail is generated by an app or 
website) but still some.
Also down but still existent is commercial mail sending for free email 
addresses -- somebody uses business services to send mail but the business has 
an email address in somebody else's domain (think "happy birthday" from your 
dentist, for instance).
Elizabeth Zwicky
  From: "Kelley, John" 
 To: "dmarc@ietf.org"  
 Sent: 
 Subject: [dmarc-ietf] Indirect mail flows
   
Hi.  

I'm not sure if it is too soon to start the discussion on indirect mail
flows, but theses are the chief problems we (AOL) are seeing with indirect
mail.

1. Auto Forwards, principally where the email is munged in some way
causing DKIM to fail.
2. Mailing lists; although the big ones seem to be rewriting the From
(thanks).
3. Groups (these might be considered a subset of mailing lists, but folks
seem to think of them differently)



John Kelley



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


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

Re: [dmarc-ietf] Fwd: New Version Notification for draft-kucherawy-dkim-delegate-00.txt

[Elizabeth Zwicky]

On 6/12/14, 3:59 PM, "Stephen J. Turnbull"  wrote:

>Elizabeth Zwicky writes:
>
> > I did not say that the levels were the same; I said the attackers
> > have not gone away. They are not at high volume, but they're sure
> > sitting there checking to see whether or not it's working.
>
>What you said, exactly, is
>
>   But I do, in fact, have data, and that data tells me that the
>   attackers forging our users based on stolen addressbooks have never
>   stopped; we are still blocking them now.
>
>What they were doing was sending millions, perhaps billions, of spoofed
>messages.  "Never stopped" implies they are still sending millions,
>perhaps billions, of spoofed messages.  As does "we are still."
>Do you really mean to invoke "plausible deniability"?


No, I mean to say that "never stopped" does not mean "never slowed down",
it means
"never stopped". And we are still blocking them now, every day, possibly
every minute.
The volumes are for the most part down to the levels they were after this
attack started
being used but before the onslaught began, although they go up
considerably from time to time.

Your argument was that we should turn off blocking to see what would
happen.
That only makes sense if the attackers have actually fully gone away. If
you
are still blocking them every day, at any level, there's really no need to
find
out what will happen if you stop blocking them. You don't unlock the door
when somebody
is still standing outside it rattling it to see if it will open.

Elizabeth
zwi...@yahoo-inc.com

>

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

Re: [dmarc-ietf] Change the mailing list protocol, not DMARC.

[Elizabeth Zwicky]

On 6/12/14, 9:36 AM, "Terry Zink"  wrote:

>> Franck Martin wrote:
>> 
>> I found that to build the override list for mailing list, I could log
>>DMARC rejected 
>> emails that contained a List-Id or List-Post header. Once reviewing the
>>logs 
>> (once a week, or once a month), you can make an easy decision if you
>>want to 
>> add the found IPs into your override list.
>
>That was my thinking, too.
>
>I like the idea of DKIM-Delegate but if I had to choose between doing
>Franck's whitelist [1] suggestion above, or DKIM-Delegate, I'd probably
>do the whitelist because it's less code to implement and maintain; as
>someone who fights spam we're already in the business of checking logs
>looking for patterns and doing overrides and so this would simply be one
>more pattern to look for.

Building your whitelist is a fine thing, but it doesn't replace a real
solution to allowing mail to be forwarded.

DKIM-Delegate gives you a hope of controlling whether your mail gets
accepted at other sites.
Figuring out who to whitelist at your site doesn't. And using List-Id or
List-Post only lets
you whitelist mailing lists, which are only part of the forwarder problem
-- there are also all the non-transparent forwarders (for instance,
enterprise systems which do malware filtering on mail).

Elizabeth

>
>-- Terry
>
>[1] whitelist = override the DMARC p=reject/quarantine action, not skip
>all filtering
>
>___
>dmarc mailing list
>dmarc@ietf.org
>https://www.ietf.org/mailman/listinfo/dmarc

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

Re: [dmarc-ietf] Fwd: New Version Notification for draft-kucherawy-dkim-delegate-00.txt

[Elizabeth Zwicky]

On 6/12/14, 3:10 AM, "Stephen J. Turnbull"  wrote:

>John R Levine writes:
>
> > For this application I don't see x= as much protection.  If a bad guy
> > subscribes to the list or gets messages via something like gmane, he
> > can do the mutate and spam in close to real time.
>
>Is this a practical concern, though?  The levels of spam etc that
>drove Yahoo! and AOL to "p=reject" were *huge*, and have persisted
>(according to Elizabeth Zwicky of Yahoo!) for several weeks after
>imposition of "p=reject".  The "retail" spams you describe are still
>going to have to run the obstacle course of content filtering, I would
>suppose, and x= means they have to use substantial resources to
>continually harvest new signatures.  Do-able, of course, but how much
>of a threat?


I did not say that the levels were the same; I said the attackers have
not gone away. They are not at high volume, but they're sure sitting
there checking to see whether or not it's working.

x= is a weak protection here; spammers can and do move millions of
messages a minute to us. Then again we are well placed to implement
special handling here, as are most if not all sites receiving mail
at this kind of scale. So the problem is at small and intermediate
sites.

Elizabeth


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

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

Re: [dmarc-ietf] DKIM through mailing lists (rebutting MLs won't change)

[Elizabeth Zwicky]

On 6/3/14, 4:26 AM, "Stephen J. Turnbull"  wrote:

>Elizabeth Zwicky writes:
>
> > At this point, I do not see going to p=quarantine in the hope
> > that attackers won't exploit data they already have exactly the same
> > way
>
>Has Yahoo! has already tried 'p=quarantine', or is that merely your
>expert opinion?  (Nothing against expertise, but "experiment" beats
>"expertise" 10 letters to 9 in my dictionary.)
>
>Obviously, there is a risk to Yahoo! in experimenting.

That risk is not one my management team is willing to accept.

But I do, in fact, have data, and that data tells me that the attackers
forging our users based on stolen addressbooks have never stopped; we are
still blocking them now. So I don't need to turn on p=quarantine to see
what will happen -- I know at least one thing that will happen. The only
question is how the volume will change.

By the way, yahoo.co.jp is an independent company with a separate mail
system and a separate account database.

Elizabeth Zwicky
zwi...@yahoo-inc.com

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

Re: [dmarc-ietf] Yet another mailing list solution thread

[Elizabeth Zwicky]

Whitelisting mailing well-behaved mailing lists is a hole, but not in general a 
horrible one; the problems are receiver consistency, scaling and maintenance, 
and they are pretty intractable.

One variant of the minimal DKIM signature which has been suggested to me is to 
double-sign, with a minimal signature and a protective one using two different 
selectors. That is currently pointless (if not actually dangerous, because it's 
very implementation-dependent what receivers will do in this situation), but 
there are some possible forward paths from there. I don't think I'm enthused, 
but it's a novel concept.

A mailing-list and receiver change option that has also been suggested to me is 
to have mailing lists include the original message as a MIME component -- you 
can then verify the signature on the original message and do some kind of 
comparison to the new one and decide how you feel about it. Again, it's a 
future-work solution.

Elizabeth
zwi...@yahoo-inc.com

From: Brandon Long mailto:bl...@google.com>>
Date: Friday, May 30, 2014 at 1:13 AM
To: "dmarc@ietf.org" 
mailto:dmarc@ietf.org>>
Subject: [dmarc-ietf] Yet another mailing list solution thread


What can DMARC enforcing domains do right now:
1) Whitelist mailing lists from enforcement.  This is obviously a hole in DMARC 
which lowers the overall utility.  Its basically saying "we don't trust your 
p=REJECT, we'll sometimes downgrade it to p=QUARANTINE".

2) Put a really simple DKIM signature on messages which doesn't cover the 
subject/body.  Ick, but it could theoretically be done.

The Future
1) Support Original-Authentication-Results.  This requires the MLM to add them 
in the first place, and for the DMARC enforcing domains to check them.  Has an 
open question of how best to "trust" the OAR header on a message.  Options 
there are explicit whitelists from the sending domains (tpa-labels or whatever) 
or to leave it up to the individual receiving domain.

2) A new mailing list specific DKIM canonicalization.  Its unlikely to be 
possible to be 100% authentication, its open for debate whether we could come 
up with one that'll provide some level of auth that may be useful in a more 
complicated "spam/phishing evaluation".

3) Some sort of "permission to relay" token.  This is pretty similar to the 
DKIM above.

4) Plain old whitelisting (tpa-labels or whatever).  Personally, I think 
without AuthRes/OAR, this is too big a hole to be useful.

5) More radical changes to MLMs/clients such as defining new headers with 
associated client requirements (ie, the footer / subject prefix is 
theoretically redundant with the adoptions of List-* headers).  Other 
alternatives include embedding the original message in a wrapper (a 
message/digest of one).  Are there any other clients besides mutt which handle 
this well?

Other ideas?

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

Re: [dmarc-ietf] DKIM through mailing lists (rebutting MLs won't change)

[Elizabeth Zwicky]

It is true that when attackers can't use our From: lines, they
try other things. 

Empirically, it's also clear that the attackers do not like

From: "Victim Name" 

as much as they like

From: "Victim Name" 

based on lowered volume when the second form is unavailable. Given that,
I see no reason to believe they won't go back to the second form if it
becomes available. And, taking into account Murphy's law, previous
tactics of these attackers, and the reasonable expectations of the public,
what will happen then is that they go very aggressive
at 2:00 in the morning my time, followed by a great deal of bad press.

At this point, I do not see going to p=quarantine in the hope
that attackers won't exploit data they already have exactly the same
way they did before, even though nothing is stopping them, as a reasonable
approach. 

Elizabeth
zwi...@yahoo-inc.com


On 5/31/14, 7:37 AM, "Stephen J. Turnbull"  wrote:

>Elizabeth Zwicky writes:
>
> > So changes that maintain effective protection for users who are
> > being targeted by attackers with addressbook information, with less
> > disruption to email that people want, are of great interest to us.
>
>How about trying "p=quarantine" with a real short TTL just in case?
>After a while you crank it back up to the current level (which is only
>1800 in any case).
>
>The argument is that, seriously, since the attackers have addressbook
>information, you're done for anyway.  They're already hard at work on
>Plan B, using "I'm writing this from my friend's account" with self in
>Sender: (should work well on Outlook users despite having on-behalf-of
>point the wrong direction), and ...  Heck, I've already thought of a
>dozen of these dodges and my name isn't even Laurence Canter.
>
>I think it's worth a check to see if the miscreants will bother to
>come back at you with the previous style of spam shot even though they
>should expect that the vast majority of their spam will get rejected
>anyway (messages apparently from a "p=quarantine" domain should be
>given a rough time as encouraged by the DMARC protocol), and the rest
>will end up in spam folders.  I would think trying to avoid DMARC
>entirely would now be the best use of their resources, so maintaining
>quarantine should be enough.  There may be some directly relevant
>recent evidence on this, since GMail is evidently promoting mailing
>list traffic from "p=reject" domains to "quarantine".  If the spammers
>know this, they could continue targeting GMail customers in their
>stolen addressbook database.  Dunno if GMail will tell Yahoo!, but you
>could ask.
>
>BTW I hope you guys are basing "p=reject" (vs. "p=quarantine") on real
>data on how often fraudulent mail that ends up in spam folders
>actually succeeds in harming the targeted victim.
>

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

Re: [dmarc-ietf] DKIM through mailing lists (rebutting MLs won't change)

[Elizabeth Zwicky]

On 5/29/14, 8:44 PM, "Scott Kitterman"  wrote:

>DMARC change is even more off the table than MLM software change (which
>does,
>as you suggest, evolve over time).

DMARC changes are not off the table for Yahoo. Right now, the option that
best serves the majority of our customers is one that also has unpleasant
consequences for a significant number of people (our customers and
others). We would vastly, vastly prefer a world where that was not true,
or even where it was less true.
So changes that maintain effective protection for users who are being
targeted by attackers with addressbook information, with less disruption
to email that people want, are of great interest to us.

    Elizabeth Zwicky
zwi...@yahoo-inc.com

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

Re: [dmarc-ietf] XML empty sp tag

[Elizabeth Zwicky]

Somebody determined along the way that the default minOccurs in this XML is 1.
On the other hand,  does occur -- the question is whether it is 
syntactically valid for it to be null, which, as far as I can tell, it is not 
(it's an enumeration of strings).

As Roland points out, that leaves the question of what you're supposed to do if 
the sender's domain has a syntactically invalid DMARC record, and producing a 
matching, harmlessly incorrect report looks like the least bad option, at least 
unless we want to change dispositionType to have INVALID as a possible value.

Elizabeth

From: Tomki Camp mailto:tc...@agari.com>>
Date: Sunday, February 23, 2014 12:07 PM
To: "dmarc@ietf.org" 
mailto:dmarc@ietf.org>>
Subject: [dmarc-ietf] XML empty sp tag

I am seeing some RUA reports come in where an sp tag is present in the XML, but 
with no value.

Such as:
  
yahoo.com
r
r
none

100
  

It’s unclear to me, from the spec, whether this is allowed.

The schema definition 
http://www.blackops.org/~msk/dmarc/draft-dmarc-base.html#xml_schema shows that 
PolicyPublishedType has both the p and sp elements as DispositionType, neither 
of them with a minOccurs.  At the very least, the former probably should have 
that, right?

What would be an appropriate way to indicate in the spec whether the empty sp 
tagset is allowed, and what it indicates?


Regards,
—Tomki


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

Re: [dmarc-ietf] ADSP to Historic?

[Elizabeth Zwicky]

+1. The only uptake we've noticed is from people who complain that the name 
returns a non-TXT non-fail for yahoo.com (which the standard says is a 
legitimate case meaning "there is no ADSP record here, move on"). So uptake 
looks both minimal and buggy.

Elizabeth

From: Krish Vitaldevara mailto:kris...@microsoft.com>>
Date: Thursday, September 12, 2013 7:33 AM
To: Paul Midgen mailto:pmi...@messagebus.com>>, Dave 
Crocker mailto:dcroc...@gmail.com>>
Cc: "dmarc@ietf.org" 
mailto:dmarc@ietf.org>>
Subject: Re: [dmarc-ietf] ADSP to Historic?

+1.

And Paul, the numbers didn’t change much there.


From: dmarc-boun...@ietf.org 
[mailto:dmarc-boun...@ietf.org] On Behalf Of Paul Midgen
Sent: Wednesday, September 11, 2013 4:12 PM
To: Dave Crocker
Cc: dmarc@ietf.org
Subject: Re: [dmarc-ietf] ADSP to Historic?

ok. i know this area can be a polarizing issue, but when i planned the SPF 
implementation at hotmail a few years ago, i also researched the use of ADSP on 
our inbound mail and found that ADSP records existed for less than 0.003% of 
traffic where it would ostensibly have been used, and that any effect it would 
have had was utterly and indisputably dwarfed first by an internal domain 
policy system, then by DMARC.

in my case it was hello nail, meet coffin.

disclaimers: i am no longer a hotmail employee. that data is now at least 2 
years old. there is a good chance that i'm off by a zero in either direction 
(not that it matters much in this case). if you want current data to bolster 
your case i can connect you offline with some former colleagues.

From: Dave Crocker mailto:dcroc...@gmail.com>>
Date: Wednesday, September 11, 2013 4:03 PM
To: Paul Midgen mailto:pmi...@messagebus.com>>
Cc: "dmarc@ietf.org" 
mailto:dmarc@ietf.org>>
Subject: Re: [dmarc-ietf] ADSP to Historic?

On 9/11/2013 3:43 PM, Paul Midgen wrote:
do you just need votes in support or something else?

my vote in support: +1 to historical.

awaiting instructions on "something else". ;)


just looking for initial reactions, to judge whether to make the formal
request.  a +/- 1 certainly qualifies.

thanks.

d/
--
Dave Crocker
Brandenburg InternetWorking
bbiw.net

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