Re: [dmarc-discuss] Some DMARC adoption data

[John Levine via dmarc-discuss]

It appears that Alessandro Vesely via dmarc-discuss  said:
>Study on Domain Name System (DNS) abuse : technical report. Appendix 1, 2022
>https://data.europa.eu/doi/10.2759/473317
>
>Chapter 17 of the Appendix (2nd link above) contains data on SPF and DMARC.
>
>The DMARC part says that 8,129,795 out of 246,425,997 domains exhibit a DMARC 
>record (3.3%).  Parsing DMARC records shows that 49.68% of the domain names 
>with the DMARC record has p=none, 11.20% have p=quarantine, and 37.14% have 
>p=reject.

I wish they'd also looked at how many domains have MX records, or had SPF -all. 

I can't get too worried about no DMARC on a domain that doesn't send or recieve 
mail.

___
dmarc-discuss mailing list
dmarc-discuss@dmarc.org
http://www.dmarc.org/mailman/listinfo/dmarc-discuss

NOTE: Participating in this list means you agree to the DMARC Note Well terms 
(http://www.dmarc.org/note_well.html)

Re: [dmarc-discuss] Why is this dmarc report from google all garbled?

[John Levine via dmarc-discuss]

It appears that Sean Malloy via dmarc-discuss  said:
>-=-=-=-=-=-
>I work for a MSP and we recently added an spf TXT record and Dmarc TXT record 
>for a clients dns. We have a DL setup in the clients o365 tenant
>that send an email to our ticketing system whenever something from the dmarc 
>triggers an email to the DL. Today in our ticketing system we got
>a ticket that looks like this, and I am not sure why: Any feedback would be 
>great.

If you send DMARC reports to a ticketing system, I don't think you will be 
happy with the results.

That's a DMARC aggregate report which has an attached ZIP file containing a 
bunch of XML
which is the report.  I see 
"google.com!lynnhrconsulting.com!1640822400!1640908799.xml" which
is the name of the report file inside the ZIP file. The rest is what happens if 
your ticketing
system doesn't know what to do with an attached ZIP file.

R's,
John

>
>From 
>noreply-dmarc-supp...@google.com: PK
>2RŸS‘Ø(+÷á
>9google.com!lynnhrconsulting.com!1640822400!1640908799.xmlíVMs›0½çW0¾Æw¥§þ‚öÌÈbM@ÒH"‰ÿ}%#>Ú¤‡›ñ
>ñv÷í¾}büô6ôÑhÃ¥xÜ¥q²‹@0YsÑ>î~ýü±/wÑyÀ
>@}¡ì™¡P¯¥ˆ"*Ì+h”å§Ó±L×ûú‰8Èà5É˲8é±,Ê4Í’âP1ZÃSº“
>•¦¢
>bt–’žò¤Ì²çVʤžçÔòuÙ„‘£fPqEò$N“"β$.s×a   Ì©LŽÂ5Ãh:Ìpè/´Ýîê9àÂ’†[w‡ÃÜ[d“ç—и›å–}Á
>QÔ¯¸YZ¢{:³fe˜× ,o¸û‚–²h
>ºj´þaÒ6#P¾#Ât´]¥Á®Ü›ñ>sÂ}÷ñ 3¼,R×Ë€þnì“g[?åð!.‹»Ã_Ûáâpwø;|(â"»;ü_9ŒÑú·öPK
>
>2RŸS‘Ø(+÷á  9google.com!lynnhrconsulting.com!1640822400!1640908799.xmlPKgN
>
>
>Thanks,
>
>Sean Malloy
>TeamLogic IT
>629-229-7603
>smal...@teamlogicit.com
___
dmarc-discuss mailing list
dmarc-discuss@dmarc.org
http://www.dmarc.org/mailman/listinfo/dmarc-discuss

NOTE: Participating in this list means you agree to the DMARC Note Well terms 
(http://www.dmarc.org/note_well.html)

Re: [dmarc-discuss] Heterogeneity in handling non-OD inputs among web-based DMARC checking tools

[John Levine via dmarc-discuss]

It appears that Scott Kitterman via dmarc-discuss  said:
>> osx:~ test$ dig _dmarc.gov.in txt

>> Does RFC 7489 allow an eTLD to set up a DMARC record?
>
>It does not.  RFC 9091 does.

Also keep in mind that with the planned change from PSL to tree walk, the 
distinction
between org domain and eTLD becomes rather fuzzy.  This is not a bug.

R's,
John
___
dmarc-discuss mailing list
dmarc-discuss@dmarc.org
http://www.dmarc.org/mailman/listinfo/dmarc-discuss

NOTE: Participating in this list means you agree to the DMARC Note Well terms 
(http://www.dmarc.org/note_well.html)

Re: [dmarc-discuss] Correct counting of DNS lookups for SPF record containing MX mechanism

[John Levine via dmarc-discuss]

It appears that Alessandro Vesely via dmarc-discuss  said:

>I see.  I note that the examples you mention, except some kind of marketing, 
>need to receive mail, besides sending it.  Indeed, being bidirectional is a 
>peculiar email characteristics.  So, if a service can be integrated with a 
>mail 
>system, then it should be able to use its incoming as well as outgoing 
>servers. 
>  Otherwise, it deserves using its own subdomain.

Sorry, but that's just silly.  Nobody ever said that inbound and outbound mail
has to take the same path.

>>> Dmarcian has a good SPF compiler already.  It is somewhat unpractical, as 
>>> you'd
>>> need to copy its result to your zone file, and repeat that operation as 
>>> often
>>> as needed.  It doesn't sound awful to call it from a cron job.
>> 
>> This is a *vastly* higher level of technical expertise than most 
>> organisations 
>> have available for this.
>
>Most likely, technology-impaired companies don't even host their own DNS.  The 
>DNS providers who do that for them should have an adequate level of expertise, 
>though.

Please excuse me while I chuckle.  You've seen how many screwed up SPF records 
there are.

Whatever the reason was to limit SPF to 10 lookups, on today's Internet there 
is no
point, and the change to increase the limit, unlike what you're proposing, is 
trivial to implement.

R's,
John
___
dmarc-discuss mailing list
dmarc-discuss@dmarc.org
http://www.dmarc.org/mailman/listinfo/dmarc-discuss

NOTE: Participating in this list means you agree to the DMARC Note Well terms 
(http://www.dmarc.org/note_well.html)

Re: [dmarc-discuss] Correct counting of DNS lookups for SPF record containing MX mechanism

[John Levine via dmarc-discuss]

It appears that Alessandro Vesely via dmarc-discuss  said:
>> I'd suggest that a resolution to this might be to expand the finite limit 
>> (I've 
>> also had trouble with the 10 lookup limit, even for a small organisation), 
>
>Why do organizations need more than 10 lookups?  Do they have a choice of 
>several smart hosts?  (And the latter need, to avail of reputed smart hosts, 
>keeps looking to me like a DMARC failure.)

Because they contract out their mail to several providers and include all those
providers' SPF records.  I agree that many of those providers use too many 
records
(e.g., _spf.google.com is four records that easily could have been one) but you
can't legislate being smart.

>An "SPF compiler" could gather a ton of addresses and dynamically assign them 
>to the.only.a.mechanism.U.need.example.com.

It could, but it'd be a lot easier to find the constant "10" in your SPF library
and change it to something like 50.  While you're at it, get rid of the empty
result limit which screws up IPv6 checks.

R's,
John
___
dmarc-discuss mailing list
dmarc-discuss@dmarc.org
http://www.dmarc.org/mailman/listinfo/dmarc-discuss

NOTE: Participating in this list means you agree to the DMARC Note Well terms 
(http://www.dmarc.org/note_well.html)

Re: [dmarc-discuss] Correct counting of DNS lookups for SPF record containing MX mechanism

[John Levine via dmarc-discuss]

It appears that Alexander NAZARIAN via dmarc-discuss 
 said:
>So I want to understand whether having MX placed in the beginning of SPF
>record can cause a quicker reach of '10 DNS lookup limitation' for G Suite
>senders, due to the reason that G Suite has 5 MX records (and I assume that
>number of DNS queries, executed to resolve MXes to IPs, is 6 and not 1)

I think he already answered that question. Different implementations
of SPF interpret the counting rule differently, so if you want your
mail delivered, assume that they will use the largest count. If you
are checking else's mail, use the smallest count. This is the well
known robustness principle about interpreting ambiguous specs.

This particular case has not come up in the past because, in practice,
the only sites that use "mx" are tiny sites with a single mail host
with a single address. It doesn't make a lot of sense for secondary MX
hosts to be sending mail for someone's domain.

I also think that some of the advice about limits in 7208 is not very good.  
For example.
you are likely to get different NOERROR counts evalating an ipv4 address than 
evaluating
an ipv6 addresss since there are lots of hosts with A records but no .

___
dmarc-discuss mailing list
dmarc-discuss@dmarc.org
http://www.dmarc.org/mailman/listinfo/dmarc-discuss

NOTE: Participating in this list means you agree to the DMARC Note Well terms 
(http://www.dmarc.org/note_well.html)

Re: [dmarc-discuss] Need documents to achieve DMARC alignment

[John Levine via dmarc-discuss]

In article  
you write:
>-=-=-=-=-=-
>-=-=-=-=-=-
>
>On Thu, Sep 24, 2020 at 11:44 PM Blason R via dmarc-discuss <
>dmarc-discuss@dmarc.org> wrote:
>
>> Thanks that makes sense! Assuming they do not have a DKIM facility
>> aligning messages with SPF should suffice my need, right? ...

>My question to you is why, in 2020, you would use a 3rd party vendor that
>does not properly support DKIM signing and apparently doesn't understand
>how DMARC works? A knowledgeable vendor should be able to provide you with
>a 1 or 2 page PDF to guide you in how to best implement SPF/DKIM/DMARC.
>Just saying.

Mike is too polite to say that any mail provider that doesn't already
understand DKIM, SPF, and DMARC, has shown that it is astonishingly
unfamiliar with the way that mail works and is unlikely to be able to
provide adequate service.

R's,
John

___
dmarc-discuss mailing list
dmarc-discuss@dmarc.org
http://www.dmarc.org/mailman/listinfo/dmarc-discuss

NOTE: Participating in this list means you agree to the DMARC Note Well terms 
(http://www.dmarc.org/note_well.html)

Re: [dmarc-discuss] Thoughts for new value 'p=nomail'

[John Levine via dmarc-discuss]

In article  
you write:
>-=-=-=-=-=-
>-=-=-=-=-=-
>
>With some of my recent DMARC reports for my domains I've seen comments
>about over riding the p=reject and deciding the mail should be quarantined
>vs rejected because the recipient mailbox provider thought it was
>forwarded.
>
>Would it be useful to add an additional DMARC be expanded to have a
>'p=nomail' value so when a domain that is already publishing "v=spf1 -all"
>and has a 'p=reject' value that it really should be rejected regardless of
>what the recipient domain thinks about a mail being forwarded or not?

We already have SPF "v=spf1 -all" to say that a domain sends no mail,
and MX 0 . to say that it receives no mail. In general it's not a
great idea to invent multiple ways to say the same thing, or to look
at it another way, if recipients aren't taking the hint from SPF, why
do we think they'd pay attention to a similar hint from DMARC?

R's,
John
___
dmarc-discuss mailing list
dmarc-discuss@dmarc.org
http://www.dmarc.org/mailman/listinfo/dmarc-discuss

NOTE: Participating in this list means you agree to the DMARC Note Well terms 
(http://www.dmarc.org/note_well.html)

Re: [dmarc-discuss] Speaking of mail security

[John Levine via dmarc-discuss]

In article <20200621184250.ga59...@kiel.esmtp.org> you write:
>On Sun, Jun 21, 2020, John Levine via dmarc-discuss wrote:
>
>> sendmail 8.14.5 from 2011 that doesn't offer STARTTLS.
>
>AFAICT ESMTPS is used when the host sends mail,
>so that's just a configuration issue (no server cert?)

I looked at the logs and you're right.  Mail is sent
with TLS but not received.

___
dmarc-discuss mailing list
dmarc-discuss@dmarc.org
http://www.dmarc.org/mailman/listinfo/dmarc-discuss

NOTE: Participating in this list means you agree to the DMARC Note Well terms 
(http://www.dmarc.org/note_well.html)

[dmarc-discuss] Speaking of mail security

[John Levine via dmarc-discuss]

A peek at the mail logs reveals that this list is hosted at
dragon.trusteddomain.org which is running an antique version of
sendmail 8.14.5 from 2011 that doesn't offer STARTTLS.

I believe that the upgrade to 8.15.2, released in 2015 but still the
most recent version, is straightforward.

R's,
John




-- 
Regards,
John Levine, jo...@taugh.com, Primary Perpetrator of "The Internet for Dummies",
Please consider the environment before reading this e-mail. https://jl.ly
___
dmarc-discuss mailing list
dmarc-discuss@dmarc.org
http://www.dmarc.org/mailman/listinfo/dmarc-discuss

NOTE: Participating in this list means you agree to the DMARC Note Well terms 
(http://www.dmarc.org/note_well.html)

Re: [dmarc-discuss] DKIM Pass for unauthorized servers?

[John Levine via dmarc-discuss]

In article <3e3d6e63-2f2e-40b9-adc5-f5638f21f...@bexx.com> you write:
>I am new to DMARC But I am seeing summary reports containing DKIM=pass 
>SPF=fail for server(s) that should not be able to send email on our behalf.
>I have seen this for more than one server/domain as I assist with a number of 
>installations. 
>
>How can another server have my freshly generated DKIM?

It can relay the message, as a courtesy forwarard or through a mailing
list if the list happens not to modify the message in ways that break
the signature.

This is definitely a feature, not a bug. If the DKIM signature is
valid, it means it's your message and you should be pleased that the
receipient is getting it unmodified.

-- 
Regards,
John Levine, jo...@taugh.com, Primary Perpetrator of "The Internet for Dummies",
Please consider the environment before reading this e-mail. https://jl.ly
___
dmarc-discuss mailing list
dmarc-discuss@dmarc.org
http://www.dmarc.org/mailman/listinfo/dmarc-discuss

NOTE: Participating in this list means you agree to the DMARC Note Well terms 
(http://www.dmarc.org/note_well.html)

Re: [dmarc-discuss] SPF and DKIM

[John Levine via dmarc-discuss]

In article  
you write:

>Can we enable DMARC just by enabling only SPF?, without DKIM? If it's
>possible what are the issues we will come across without DKIM?

I would encourage you not to do that. As others have said, it sort of
works until there is any sort of forwarding. I can report that there
is a lot more forwarding than most people realize, typically some sort
of organizational or role account forwarded to a private mailbox for
the person in the role.

You might be able to check the "DMARC compliant" box but I don't think
you would be happy with the amount of real mail you will lose,
particularly if the mail is anything other than broadcast
advertisements.

 

___
dmarc-discuss mailing list
dmarc-discuss@dmarc.org
http://www.dmarc.org/mailman/listinfo/dmarc-discuss

NOTE: Participating in this list means you agree to the DMARC Note Well terms 
(http://www.dmarc.org/note_well.html)

Re: [dmarc-discuss] Ranked domains that advertise RUA addresses and then bounce aggregate reports sent to them

[John Levine via dmarc-discuss]

In article <65960f35-16b5-7889-5db1-c5c678015...@kamens.us> you write:
>For your edification, below, in domain rank order (from the
>https://domcop.com/openpagerank/ API), are the ranked domains that have
>bounced at least one DMARC aggregate report my mail server has tried to
>send them since I started tracking this in September 2018.
>
>There are a lot of domains on this list that are big enough that they
>really should be able to handle something as critical as not bouncing
>aggregate reports sent to the email address they advertise for them.

One rejected report in about 500 days is an 0.2% bounce rate.  That seems
a bit extreme.

Do you have an idea of why they're being rejected?  Yahoo in
particular sometimes has bad days (I think due to DDoS) and defers or
fails to accept mail to anyone.  It's nothing personal.

___
dmarc-discuss mailing list
dmarc-discuss@dmarc.org
http://www.dmarc.org/mailman/listinfo/dmarc-discuss

NOTE: Participating in this list means you agree to the DMARC Note Well terms 
(http://www.dmarc.org/note_well.html)

Re: [dmarc-discuss] DMARC vs DKIM keys with s=mtasts

[John Levine via dmarc-discuss]

In article  you write:
>-=-=-=-=-=-
>-=-=-=-=-=-
>
>My 2 cents, if we are validating an email then the services MUST cover email, 
>either by including '*' or 'email'. Regardless of what
>attachments that email contains.
>
>RFC8460 appears to conflict with 6376 in this regard, and with that
in mind 8460 should be updated to suggest s=email:tlsrpt or s=*

Or it could have separate signatures, one for the MTA with s=email and one
for the mtasts consumer with s=tlsrpt.

I honestly do not understand what problem the s=tlsrpt signature is
supposed to solve.  It can't have anything to do with authentication
or security, since the alternative HTTPS transport has neither.  As
far as I can tell, to the extent anyone implements s=tlsrpt
signatures, they just make it an alias for s=email with no opportunity
for validators to choose.

I'm inclined to submit an erratum and say the s=tlsrpt signature language
was a mistake.

R's,
John
___
dmarc-discuss mailing list
dmarc-discuss@dmarc.org
http://www.dmarc.org/mailman/listinfo/dmarc-discuss

NOTE: Participating in this list means you agree to the DMARC Note Well terms 
(http://www.dmarc.org/note_well.html)

Re: [dmarc-discuss] DMARC vs DKIM keys with s=mtasts

[John Levine via dmarc-discuss]

In article <623afe11-a57e-49f3-b845-7e48a9ae5...@kitterman.com> you write:
>I don't think 8460 needed to update 6376, since valid service values are 
>defined by the registry, not by 6376.  The mistake was
>not updating the registry.
>
>After looking at it again, I see your point about ignoring unknown service 
>types.  I agree a second signature for regular email
>stream validation (e.g. DMARC) would make sense.

Agreed.  It's worth clarifying that the s=tlsrpt signature is purely
for the benefit of RFC8460 report consumers and will have no effect on
the process of getting the message to that consumer through the mail
stream.  And if you really want to do that, there should be a way to
tell the DKIM verifier called by the report consumer to look for a
tlsrpt signature, not an email signature.

The whole thing still seems like gratuitous overkill.  If you deliver
the report by https POST, there's no validation of the report sender
at all.

-- 
Regards,
John Levine, jo...@taugh.com, Primary Perpetrator of "The Internet for Dummies",
Please consider the environment before reading this e-mail. https://jl.ly
___
dmarc-discuss mailing list
dmarc-discuss@dmarc.org
http://www.dmarc.org/mailman/listinfo/dmarc-discuss

NOTE: Participating in this list means you agree to the DMARC Note Well terms 
(http://www.dmarc.org/note_well.html)

Re: [dmarc-discuss] DMARC vs DKIM keys with s=mtasts

[John Levine via dmarc-discuss]

In article <3074162.RNaZIRUnTP@l5580> you write:
>RFC 6376, Section 3.6.1, in the s= paragraphs says:
>
>> *  matches all service types
>
>If libopendkim and Mail::DKIM are looking for a literal '*' as the service 
>type, rather than accepting any value for service type, they are buggy and 
>should be fixed AFAICT.

If there's an s= tag, they accept "*" or a colon separated list that
contains "email".  My locally patched libopendkim does what pydkim
does and also accepts a list with "tlsrpt".

The language in 6376 says if a key record has an s= tag and it doesn't
have a value we like, we ignore the record.  That's why the DKIM
signatures with s=tlsrpt don't validate, since that's not a key that's
valid for the 'email' service.

>> RFC 8460 says the key SHOULD have s=tlsrpt and the recipient MAY ignore
>> reports without that service type.  I'm inclined to consider that an error
>> in view of experience with it.  Different service types are for messages
>> delivered some way other than SMTP.
>
>I'm not sure that follows if service types are correctly processed.  I am 
>curious what you think it a kludge in dkimpy?

Since RFC 8460 doesn't update 6376, I'm confident that an s=tlsrpt key
shouldn't validate a signature on ordinary e-mail not intended as a
TLS report.  Arguably, it shouldn't validate e-mail even if it *is*
intended as a report, since the spec says s= is there for "other
services" and TLS reports aren't another service, they're e-mail.  If
you want to make RFC 8460 happy, add another signature separate from
the one that email uses.

My recollection from back when that language was written 15 years ago
is that we meant service in the RFC 6335 sense, different things that
would never show up in the same stream as e-mail messages.  The
specific example was signing SIP headers, which I think would have
been a better idea than much more complex STIR/SHAKEN.  It still might
be interesting to put DKIM signatures on HTTP messages.

R's,
John


___
dmarc-discuss mailing list
dmarc-discuss@dmarc.org
http://www.dmarc.org/mailman/listinfo/dmarc-discuss

NOTE: Participating in this list means you agree to the DMARC Note Well terms 
(http://www.dmarc.org/note_well.html)

Re: [dmarc-discuss] DMARC is not disabled automatically at Office 365 when the MX is different

[John Levine via dmarc-discuss]

In article  
you write:
>Dumb question time. In that scenario, if mail is forwarded with the
>DKIM signature intact, would that be good enough to still pass DMARC?
>Or will it fail because SPF now fails?

Assuming no gratuitous changes to the message, yes.  But I've found a
dismaying number of people only using SPF and publishing p=reject
anyway.

As someone else noted, this is really a bug in the configuration, since the 
system doing
the DMARC evaluation should do it relative to the MX, not some later hop.

R's,
John

-- 
Regards,
John Levine, jo...@taugh.com, Primary Perpetrator of "The Internet for Dummies",
Please consider the environment before reading this e-mail. https://jl.ly
___
dmarc-discuss mailing list
dmarc-discuss@dmarc.org
http://www.dmarc.org/mailman/listinfo/dmarc-discuss

NOTE: Participating in this list means you agree to the DMARC Note Well terms 
(http://www.dmarc.org/note_well.html)

Re: [dmarc-discuss] Basic questions

[John Levine via dmarc-discuss]

In article  you write:
>-=-=-=-=-=-
>-=-=-=-=-=-
>
>I have some basic questions about the implementation of DMARC policies after 
>reading some of the official documentation.
>
>For "p=quarantine", "rua=mailto:postmas...@example.biz; (if specified) should 
>receive periodic spam reports, correct?

Nope.  The policy and reporting are unrelated.  Recipients send a
daily summary of *all* of the mail they get with your domain on the
From: line, aligned or unaligned.  My policies are all p=none and I
get lots of rua= reports.

>If "p=reject", then "ruf=mailto:postmas...@example.biz; is basically a "bounce 
>address" for rejected messages, but if "ruf=mailto:; is
>not going to be specified, then why would someone even consider specifying 
>"p=reject" rather than "p=quarantine"?

Nope.  p=reject means the domain suggests you reject the message in the SMTP 
session.

ruf= is for any message that is unaligned, regardless of what the recipient did 
with it.
In practice almost nobody sends ruf= reports because of their privacy issues.


>Then there is the "pct=xx" parameter for the chosen policy.
>
>Does this mean that the chosen "p=" policy is intended to be applied uniformly 
>at random (by a probabilistic lottery) to messages that
>fail the DMARC check, or by a more sophisticated method designed to catch the 
>"spammiest"  xx% of messages failing the full DMARC
>check?

The former.  

DMARC has nothing to do with what's "spammiest".  I get tons of spam
that is 100% DMARC compliant, while users of discussion lists like
this one know that there is plenty of real mail that is unaligned
because of DMARC's limitations.

-- 
Regards,
John Levine, jo...@taugh.com, Primary Perpetrator of "The Internet for Dummies",
Please consider the environment before reading this e-mail. https://jl.ly
___
dmarc-discuss mailing list
dmarc-discuss@dmarc.org
http://www.dmarc.org/mailman/listinfo/dmarc-discuss

NOTE: Participating in this list means you agree to the DMARC Note Well terms 
(http://www.dmarc.org/note_well.html)

Re: [dmarc-discuss] Know anyone working on ARC at Microsoft ?

[John Levine via dmarc-discuss]

In article <0746ea03-c242-1020-7df8-f087f58a0...@crash.com> you write:
>But yes, it's also worth noting that the item posted to the "Microsoft 
>365 Roadmap" at the end of October only discussed the use of ARC when 
>receiving messages for mailboxes hosted by Microsoft. It didn't address 
>any use of ARC in messages received from Microsoft by other entities.

Understood, but I'd think that things would work better overall if
their ARC headers implemented RFC 8617 rather than some Redmond mutant.

It looks to me like they're signing a private header that's modified on
the way our or something like that.

___
dmarc-discuss mailing list
dmarc-discuss@dmarc.org
http://www.dmarc.org/mailman/listinfo/dmarc-discuss

NOTE: Participating in this list means you agree to the DMARC Note Well terms 
(http://www.dmarc.org/note_well.html)

Re: [dmarc-discuss] DMARC RUF

[John Levine via dmarc-discuss]

In article  you write:
>
>I received failure/forensic reports ("ruf=") from NetEase and Hotmail 
>for several years, for at least one small domain I operate, and I appear 
>to have received such reports from NetEase as recently as 3Q2018. None 
>from Hotmail since late 2017 though, and that was expected when 
>Microsoft merged that service into other infrastructure.

You're right, Hotmail used to send some but stopped a few years ago, Netease
used send a lot but seems to have stopped in October.

The ones from Netease were rarely useful, just random spam that
happened to forge one of my domains.  The Hotmail ones were more
likely to be mailing lists.

R's,
John
___
dmarc-discuss mailing list
dmarc-discuss@dmarc.org
http://www.dmarc.org/mailman/listinfo/dmarc-discuss

NOTE: Participating in this list means you agree to the DMARC Note Well terms 
(http://www.dmarc.org/note_well.html)

Re: [dmarc-discuss] DMARC RUF

[John Levine via dmarc-discuss]

In article  
you write:
>Can someone tell me why the mail providers have stopped sending forensic
>emails?

They haven't stopped because they never started.

Forensic messages have big privacy problems because they send a
message, or at least part of it, to someone who may or may not have
any connection to the actual sender.  No large mail system has ever
sent them.

I get a few failure reports from Linkedin and from some small networks
mostly in Europe.

___
dmarc-discuss mailing list
dmarc-discuss@dmarc.org
http://www.dmarc.org/mailman/listinfo/dmarc-discuss

NOTE: Participating in this list means you agree to the DMARC Note Well terms 
(http://www.dmarc.org/note_well.html)

Re: [dmarc-discuss] Substituted Source IP question

[John Levine via dmarc-discuss]

In article <59f825b3-ccbf-1caf-93df-98e3fb9af...@gmail.com> you write:
>Thanks Randal.  This confirms the university's view of the situation.  
>So there's some work needed to accommodate this across our mail domains.

Depending on how technically competent your university's mail managers
are, it wouldn't be terribly hard to adjust the DMARC checks to look
back one hop and do SPF checks relative to the gateway that forwards
the mail.


>It also means a mandate for SPF and DMARC w/o also specifying DKIM for 
>the From: domain is problematic.

No.  DMARC has never been able to describe every legitimate path a
message might take.  That is a fundamental limitation in DMARC, not a
failure of e-mail.


___
dmarc-discuss mailing list
dmarc-discuss@dmarc.org
http://www.dmarc.org/mailman/listinfo/dmarc-discuss

NOTE: Participating in this list means you agree to the DMARC Note Well terms 
(http://www.dmarc.org/note_well.html)

Re: [dmarc-discuss] Rua and ruf address

[John Levine via dmarc-discuss]

In article ,
Hari Hendaryanto via dmarc-discuss  wrote:
>Hi,
>
>I'm new to dmarc. I've just setting up dmarc record view weeks a go.
>
>My question is, is it okay if i set my ruf address sane as rua?

Yes, that's fine.

If you get many reports you will probably want to set up separate
addresses to make the reports easier to sort and archive.

-- 
Regards,
John Levine, jo...@iecc.com, Primary Perpetrator of "The Internet for Dummies",
Please consider the environment before reading this e-mail. https://jl.ly
___
dmarc-discuss mailing list
dmarc-discuss@dmarc.org
http://www.dmarc.org/mailman/listinfo/dmarc-discuss

NOTE: Participating in this list means you agree to the DMARC Note Well terms 
(http://www.dmarc.org/note_well.html)

Re: [dmarc-discuss] What is the end goal of DMARC?

[John Levine via dmarc-discuss]

In article ,
Alessandro Vesely via dmarc-discuss  wrote:
>I'd favor domain.INVALID.  Its only defect originates from a dubious
>reject-on-nxdomain advocacy, which would require to use domains with wildcard
>records (e.g. domain.REMOVE.DMARC.TRAILING.PARTS).

I did INVALID for a while and it was a really bad idea.  Header
addresses in a non-existent domain are a strong spam signal.  I do
wildcard *.dmarc.fail addresses and they work fine.  My mail server
knows what's been rewritten recently and rejects everything else.

>I agree it doesn't sound safe.  Even if it's only a few days, it looks amenable
>to attacks.

Having done dmarc.fail rewrites for a several years, my actual
experience is that it works fine.  The IETF does more or less the same
thing, and it works fine.  Can you be more explicit what sort of
attacks you expect, keeping in mind that they haven't happened yet?
___
dmarc-discuss mailing list
dmarc-discuss@dmarc.org
http://www.dmarc.org/mailman/listinfo/dmarc-discuss

NOTE: Participating in this list means you agree to the DMARC Note Well terms 
(http://www.dmarc.org/note_well.html)

Re: [dmarc-discuss] What is the end goal of DMARC?

[John Levine via dmarc-discuss]

In article  
you write:
>Rewriting the from address to something that fails -- and thus is
>potentially going to fail delivery at any ISP that checks to see if
>the from address is valid -- seems crappy to me. I'd rather it be
>rewritten to be the list address as this list and most others seem to
>be doing.

PS:

$ dig yahoo.com.dmarc.fail mx

; <<>> DiG 9.10.6 <<>> yahoo.com.dmarc.fail mx
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 61104
;; flags: qr rd ra ad; QUERY: 1, ANSWER: 1, AUTHORITY: 3, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;yahoo.com.dmarc.fail.  IN  MX

;; ANSWER SECTION:
yahoo.com.dmarc.fail.   3297IN  MX  20 mail1.iecc.com.

;; AUTHORITY SECTION:
dmarc.fail. 3297IN  NS  sdn.iecc.com.
dmarc.fail. 3297IN  NS  osdn.iecc.com.
dmarc.fail. 3297IN  NS  light.lightlink.com.


>> There's more than one way to rewrite a From: header, and that's the worst.
>>
>> On my system if the incoming header looks like this:
>>
>> From: Marissa 
>>
>> It gets rewritten like this:
>>
>> From: Marissa 
>>
>> The IETF does more or less the same thing but it's uglier because the
>> guy who did it believes there is something special about the three
>> characters =40 in an address.
>>
>> R's,
>> John
>> ___
>> dmarc-discuss mailing list
>> dmarc-discuss@dmarc.org
>> http://www.dmarc.org/mailman/listinfo/dmarc-discuss
>>
>> NOTE: Participating in this list means you agree to the DMARC Note Well 
>> terms (http://www.dmarc.org/note_well.html)
>
>
>
>-- 
>al iverson // 312-725-0130 // miami
>http://www.aliverson.com
>http://www.spamresource.com
>___
>dmarc-discuss mailing list
>dmarc-discuss@dmarc.org
>http://www.dmarc.org/mailman/listinfo/dmarc-discuss
>
>NOTE: Participating in this list means you agree to the DMARC Note Well terms 
>(http://www.dmarc.org/note_well.html)
>


___
dmarc-discuss mailing list
dmarc-discuss@dmarc.org
http://www.dmarc.org/mailman/listinfo/dmarc-discuss

NOTE: Participating in this list means you agree to the DMARC Note Well terms 
(http://www.dmarc.org/note_well.html)

Re: [dmarc-discuss] What is the end goal of DMARC?

[John Levine via dmarc-discuss]

In article  
you write:
>Rewriting the from address to something that fails -- and thus is
>potentially going to fail delivery at any ISP that checks to see if
>the from address is valid -- seems crappy to me.

Sorry, I don't understand what point you're making here.  Where do you
see something that fails?

R's,
John



>Regards,
>Al Iverson
>On Sat, Oct 13, 2018 at 8:01 PM John Levine via dmarc-discuss
> wrote:
>>
>> In article  you write:
>> > > When the IETF was trying to figure out what sort of anti-DMARC hackery
>> > > to do for its mailing lists, we did some experiments.  ...  So we gave
>> > > up and rewrite the From: headers.
>> >
>> >A defect in the method used in this list (and Y!Groups, fwiw) is that
>> >every message from the list comes through with the exact same email
>> >address, , in the From field.
>>
>> There's more than one way to rewrite a From: header, and that's the worst.
>>
>> On my system if the incoming header looks like this:
>>
>> From: Marissa 
>>
>> It gets rewritten like this:
>>
>> From: Marissa 
>>
>> The IETF does more or less the same thing but it's uglier because the
>> guy who did it believes there is something special about the three
>> characters =40 in an address.
>>
>> R's,
>> John
>> ___
>> dmarc-discuss mailing list
>> dmarc-discuss@dmarc.org
>> http://www.dmarc.org/mailman/listinfo/dmarc-discuss
>>
>> NOTE: Participating in this list means you agree to the DMARC Note Well 
>> terms (http://www.dmarc.org/note_well.html)
>
>
>
>-- 
>al iverson // 312-725-0130 // miami
>http://www.aliverson.com
>http://www.spamresource.com
>___
>dmarc-discuss mailing list
>dmarc-discuss@dmarc.org
>http://www.dmarc.org/mailman/listinfo/dmarc-discuss
>
>NOTE: Participating in this list means you agree to the DMARC Note Well terms 
>(http://www.dmarc.org/note_well.html)
>


___
dmarc-discuss mailing list
dmarc-discuss@dmarc.org
http://www.dmarc.org/mailman/listinfo/dmarc-discuss

NOTE: Participating in this list means you agree to the DMARC Note Well terms 
(http://www.dmarc.org/note_well.html)

Re: [dmarc-discuss] What is the end goal of DMARC?

[John Levine via dmarc-discuss]

In article  you write:
> > When the IETF was trying to figure out what sort of anti-DMARC hackery
> > to do for its mailing lists, we did some experiments.  ...  So we gave
> > up and rewrite the From: headers.
>
>A defect in the method used in this list (and Y!Groups, fwiw) is that 
>every message from the list comes through with the exact same email 
>address, , in the From field.

There's more than one way to rewrite a From: header, and that's the worst.

On my system if the incoming header looks like this:

From: Marissa 

It gets rewritten like this:

From: Marissa 

The IETF does more or less the same thing but it's uglier because the
guy who did it believes there is something special about the three
characters =40 in an address.

R's,
John
___
dmarc-discuss mailing list
dmarc-discuss@dmarc.org
http://www.dmarc.org/mailman/listinfo/dmarc-discuss

NOTE: Participating in this list means you agree to the DMARC Note Well terms 
(http://www.dmarc.org/note_well.html)

Re: [dmarc-discuss] What is the end goal of DMARC?

[John Levine via dmarc-discuss]

In article <6a515d07-5bde-cf5f-813b-749557247...@tana.it> you write:
>> It's easy enough to invent hacks that lists could apply and MUAs could
>> undo,
>
>So easy that it is already implemented by some.

When the IETF was trying to figure out what sort of anti-DMARC hackery
to do for its mailing lists, we did some experiments.  I set up a mail
reflector that took messages, added headers or wrapped them as MIME
attachements in various ways, and sent them back so people could see
how they looked.  They all looked awful, and they looked awful in
different ways in different MUAs.  So we gave up and rewrite the From:
headers.

Trying to get MUAs to do de-DMARC-ing is not a productive line of
attack.

R's,
John
___
dmarc-discuss mailing list
dmarc-discuss@dmarc.org
http://www.dmarc.org/mailman/listinfo/dmarc-discuss

NOTE: Participating in this list means you agree to the DMARC Note Well terms 
(http://www.dmarc.org/note_well.html)

Re: [dmarc-discuss] What is the end goal of DMARC?

[John Levine via dmarc-discuss]

In article <5bbf9b2b.6010...@signal100.com> you write:
>Other than rewriting headers (which of course can be done in a number of
>ways), what would you suggest?
>
>Perhaps a new RFC defining new headers which MLs can add to describe to
>mail clients exactly what has been done? This was suggested before but
>itself has drawbacks.

It's easy enough to invent hacks that lists could apply and MUAs could
undo, but the chances of MUAs all implementing them is even less than
of a critical mass of MTAs implementing ARC.

R's,
John
___
dmarc-discuss mailing list
dmarc-discuss@dmarc.org
http://www.dmarc.org/mailman/listinfo/dmarc-discuss

NOTE: Participating in this list means you agree to the DMARC Note Well terms 
(http://www.dmarc.org/note_well.html)

Re: [dmarc-discuss] What is the end goal of DMARC?

[John Levine via dmarc-discuss]

In article <963257f9-0f6b-516b-59ea-b72852a4d...@quantopian.com> you write:
>I thought the goal of DMARC was that eventually the maintainer of every 
>domain on the internet that shows up in the From: line of email messages 
>will be able to reliably tell the rest of the internet which of those 
>emails are legitimate and which are forged, ...

No.  It will give domains the option to do so, but there are plenty of
domains that have good reasons never to publish a policy other than p=none.

>For example, one poster claimed that no "mailbox provider" should ever 
>be using "p=quarantine" or "p=reject" in their DMARC policy. This 
>confuses me. If the mailbox providers, i.e., the domains which host the 
>majority of users and presumably generate the majority of emails, are 
>not expected to be able to definitively assert which emails claiming to 
>be from them are legitimate, even in a world where DMARC is properly 
>implemented everywhere, then what's the point? Again, what's the goal?

The original goal was to allow heavily phished names like paypal.com
that have firm control over their outgoing mail to tell the world that
they'd prefer that recipients reject suspicious mail EVEN THOUGH THAT
MEANS THAT SOME REAL MAIL WILL BE LOST.  Paypal is the classic example
since all the mail that Paypal sends says "log in to your account
because there's something new."

Unfortunately, a few years later AOL and Yahoo both had huge security
breaches, crooks stole millions of address books, and started to send
spam to AOL and Yahoo users with fake From: addresses of people they
know.  Then AOL and Yahoo consciously reused DMARC to outsource the
support cost of this forged mail on the rest of the world.  That's how
we got where we are now.

This is all well documented.  I hope it doesn't come as a surprise
to anyone.

R's,
John
___
dmarc-discuss mailing list
dmarc-discuss@dmarc.org
http://www.dmarc.org/mailman/listinfo/dmarc-discuss

NOTE: Participating in this list means you agree to the DMARC Note Well terms 
(http://www.dmarc.org/note_well.html)

Re: [dmarc-discuss] "p=none" vs. "p=quarantine; pct=0"

[John Levine via dmarc-discuss]

In article <29bfd7c6-00bd-0950-fee8-780746f32...@quantopian.com> you write:
>It can also be fairly argued that the maintainers of servers that host 
>mailing lists should get off their asses and fix their software to 
>rewrite headers for domains that have DMARC policies, and that they have 
>no incentive to do this as long as the mailbox providers aren't using 
>p=quarantine or p=reject.

No, they should add ARC seals so recipients can filter them reasonable.

Both Mailman and Sympa have ARC now, so for a lot of us it's just a config 
switch.

R's,
John
___
dmarc-discuss mailing list
dmarc-discuss@dmarc.org
http://www.dmarc.org/mailman/listinfo/dmarc-discuss

NOTE: Participating in this list means you agree to the DMARC Note Well terms 
(http://www.dmarc.org/note_well.html)

Re: [dmarc-discuss] "p=none" vs. "p=quarantine; pct=0"

[John Levine via dmarc-discuss]

In article <24dd5bc1-ca89-473c-9d11-cb712504c...@akamai.com> you write:
>p=none -> “we’re trying to figure out if we’re going to be able to go to 
>p=quarantine”
>
>If you treat quarantine differently than none, you’re sending me misleading 
>data in the reports you send (if of course
>you send reports) - or your downstream recipients send.

Sorry, but that is just wrong.  I publish p=none because that is my
policy.  That's what the spec says, that's what it means.

R's,
John
___
dmarc-discuss mailing list
dmarc-discuss@dmarc.org
http://www.dmarc.org/mailman/listinfo/dmarc-discuss

NOTE: Participating in this list means you agree to the DMARC Note Well terms 
(http://www.dmarc.org/note_well.html)

Re: [dmarc-discuss] Fwd: Re: Help

[John Levine via dmarc-discuss]

In article <869d643b-7594-4bad-8929-9afdea01d...@portadmiral.org> you write:
>Yes, there are folks who don’t know. I am an administrator for 17 mailing 
>lists using different technologies,
>and I belong to several more. Mailman is different from Yahoo Groups is 
>different from Google Groups is
>different from L-Soft’s listserv (where most of my lists are). And every one 
>has different subscribe and
>unsubscribe options.

The would be a good time to upgrade your mail program to one that
handles the List-Unsubscribe header that was defined in RFC 2369 in
1998 and that is present on every message sent to this list as well as
on messages from Yahoogroups and most othe list systems.  Then you're
one click away from unsubscribing for any mailing list.



> And every one of my lists has a link to unsubscribe in the footer. Just as 
> this list should
>and is required by law, at least in the US. This is the only list I have 
>encountered that does not follow this practice.

You appear to be misstating 15 USC 7704 (a)(3) which requires opt-out
contact info in commercial electronic mail messages.  Except that
"commercial electronic mail message" is defined in 15 USC 7702 (2),
and this list clearly isn't it, so the requirement doesn't apply.  (I
get to play junior lawyer because I've been an expert witness in CAN
SPAM criminal court cases.)

By the way, each message to this list does have a URL in the footer,
which does indeed lead to the mailman page where you can unsubscribe.
Try it.

R's,
John
___
dmarc-discuss mailing list
dmarc-discuss@dmarc.org
http://www.dmarc.org/mailman/listinfo/dmarc-discuss

NOTE: Participating in this list means you agree to the DMARC Note Well terms 
(http://www.dmarc.org/note_well.html)

Re: [dmarc-discuss] Help

[John Levine via dmarc-discuss]

In article  
you write:
>Might be better to have an MX record that points to localhost, because
>if you have an A record but no MX, people will just try to connect to
>the A record.

There's an RFC for that:

https://tools.ietf.org/html/rfc7505

R's,
John
-- 
Regards,
John Levine, jo...@iecc.com, Primary Perpetrator of "The Internet for Dummies",
Please consider the environment before reading this e-mail. https://jl.ly
___
dmarc-discuss mailing list
dmarc-discuss@dmarc.org
http://www.dmarc.org/mailman/listinfo/dmarc-discuss

NOTE: Participating in this list means you agree to the DMARC Note Well terms 
(http://www.dmarc.org/note_well.html)

Re: [dmarc-discuss] Email encryption services and DMARC

[John Levine via dmarc-discuss]

In article <3fe159fb-7de2-b823-2665-bcf985b6c...@rolandturner.com> you write:
>Can you show sample/likely envelopes/headers that would cause the 
>problem? It's not clear from your description why there's a problem. Are 
>you saying that Cisco is running a service that impersonates author 
>(5322.From) domains of *_non_*-customers?

It sounds to me like the bounce address is the third-party provider
and there's no DKIM signature, so there's nothing for DMARC to align
with.

Sounds to me like the answer is that if you're going to let a third
party send mail for you, it'd be a good idea to enable the third party
to put on some DKIM signatures, too.

R's,
John
___
dmarc-discuss mailing list
dmarc-discuss@dmarc.org
http://www.dmarc.org/mailman/listinfo/dmarc-discuss

NOTE: Participating in this list means you agree to the DMARC Note Well terms 
(http://www.dmarc.org/note_well.html)

Re: [dmarc-discuss] RUA vs RUF reports

[John Levine via dmarc-discuss]

In article  you write:
>I don't think you can be held responsible if a "total stranger's" email 
>ends up in your inbox because they put your domain in the From line of 
>the email without your authorization. ...

Maybe.  I gather there's all sorts of cases where it is not clear how
the operator of a domain relates to people with mail in that domain or
in that subdomain.  For example, I expect that university faculty or
company CEOs might not be thrilled that random low level IT people were
getting copies of their mail just because it happened to be forwarded
in a mildly funky way.

R's,
John
___
dmarc-discuss mailing list
dmarc-discuss@dmarc.org
http://www.dmarc.org/mailman/listinfo/dmarc-discuss

NOTE: Participating in this list means you agree to the DMARC Note Well terms 
(http://www.dmarc.org/note_well.html)

Re: [dmarc-discuss] RUA vs RUF reports

[John Levine via dmarc-discuss]

In article  you write:
>1) Most of the failure reports I've seen haven't included the message 
>body, they've only included the headers.

Depends who you get them from.  The ones from Netease are just the
headers, the ones from Linkedin give you the whole message.


>2) The people receiving the failure reports aren't "total strangers." 
>They are either (a) the same people who run the email infrastructure (if 
>failure reports are handled internally), who are presumably authorized 
>to look at email headers while troubleshooting issues, or (b) 
>third-party data processors (to use the GDPR terminology), which are 
>permitted as long as how they are using the data is disclosed to users.

They're sent to whoever some ruf= tag points to.  I get all the
failure reports for any message with one of my domains on the From:
line, even if if was forged or a typo or a configuration error and
nobody related to me sent it.  Sounds like total strangers to me.

R's,
John
___
dmarc-discuss mailing list
dmarc-discuss@dmarc.org
http://www.dmarc.org/mailman/listinfo/dmarc-discuss

NOTE: Participating in this list means you agree to the DMARC Note Well terms 
(http://www.dmarc.org/note_well.html)

Re: [dmarc-discuss] RUA vs RUF reports

[John Levine via dmarc-discuss]

In article 
 you 
write:
>I'm surprised to learn of the low value of failure reports.

It's a lawyer thing.  Failure reports send copies of your users' mail
to total strangers.  Maybe those strangers had something to do with
that mail, maybe not.  You can make various arguments about why even
if the strangers didn't have anything to do with the mail they should
get to see it anyway, but you know how lawyers are, always telling you
to spend $1000 to defend against a $10 risk.

R's,
John
___
dmarc-discuss mailing list
dmarc-discuss@dmarc.org
http://www.dmarc.org/mailman/listinfo/dmarc-discuss

NOTE: Participating in this list means you agree to the DMARC Note Well terms 
(http://www.dmarc.org/note_well.html)

Re: [dmarc-discuss] General DMARC weakness - personal forwarding

[John Levine via dmarc-discuss]

In article  
you write:
>No, ordinary forwarders which break DKIM need to ARC sign.  If you're just
>an ordinary forwarder, why break DKIM?

Unfortunately, some people still authenticate with SPF, so an unmodified forward
can break DMARC.

R's,
John
___
dmarc-discuss mailing list
dmarc-discuss@dmarc.org
http://www.dmarc.org/mailman/listinfo/dmarc-discuss

NOTE: Participating in this list means you agree to the DMARC Note Well terms 
(http://www.dmarc.org/note_well.html)

Re: [dmarc-discuss] General DMARC weakness - personal forwarding

[John Levine via dmarc-discuss]

In article <445884976.7940.1527153118...@appsuite.open-xchange.com> you write:
>This is actually an area of concern to us: how will small scale operations, 
>like a server that only hosts a handful
>of mailing lists for local non profits / open source projects / amateur groups 
>etc, be able to be recognized as
>trusted ARC intermediaries? The big players have reputation systems that could 
>be used for this as well, but what
>about everyone else?

People at big providers tell me that they're likely to seed a public
whitelist of ARC forwarders.

R's,
John
___
dmarc-discuss mailing list
dmarc-discuss@dmarc.org
http://www.dmarc.org/mailman/listinfo/dmarc-discuss

NOTE: Participating in this list means you agree to the DMARC Note Well terms 
(http://www.dmarc.org/note_well.html)

Re: [dmarc-discuss] General DMARC weakness - personal forwarding

[John Levine via dmarc-discuss]

In article  you write:
>Until then, a simple forwarding —refraining to append any disclaimer or virus
>scanning notice to the body of the message— would not break DKIM signatures and
>hence leave DMARC authenticity intact.  That is exactly the problem that DKIM
>was designed to solve, to overcome the fact that SPF breaks forwarding.

Well, unless the original sender only authenticated with SPF.

It's a mess.

> Finally, user+al...@dom.ain is not standard.

It's a perfectly standard RFC 5321/5322 address.  The way it's
interpreted by the recipient MTA is up to that MTA, but the
way that *any* address is interpreted is up to the recipient MTA.

R's,
John
___
dmarc-discuss mailing list
dmarc-discuss@dmarc.org
http://www.dmarc.org/mailman/listinfo/dmarc-discuss

NOTE: Participating in this list means you agree to the DMARC Note Well terms 
(http://www.dmarc.org/note_well.html)

Re: [dmarc-discuss] DMARC Reporting De-duplication

[John Levine via dmarc-discuss]

In article <1675430.NNnUSil6oV@kitterma-e6430> you write:
>As an example, I have been able to find four messages I sent to 
>lists.debian.org email lists on April 30th.  The volume reported for that 
>source for that day from various feedback reporters was 2,436.  This makes it 
>a little hard to consume the feedback.

My feedback goes into a database where I do occasional summary
queries.  I don't recall any particular problems doing the analysis
and it is kind of fun to extract numbers like how many NANOG
subscribers get their mail at Gmail.

If a future DMARC 1.01 had deduped reports, some would be deduped,
some wouldn't, and it'd be if anything harder to find the signal
in the noise.

R's,
John
___
dmarc-discuss mailing list
dmarc-discuss@dmarc.org
http://www.dmarc.org/mailman/listinfo/dmarc-discuss

NOTE: Participating in this list means you agree to the DMARC Note Well terms 
(http://www.dmarc.org/note_well.html)

Re: [dmarc-discuss] DMARC report to external domain

[John Levine via dmarc-discuss]

In article <00c026d7356944adb32b5f654ab07...@infineon.com> you write:
>May I know how to create the this DNS record? Any sample?

Try looking up the TXT record for ._report._dmarc.abuse.net

$ dig example.com._report._dmarc.abuse.net txt

;; QUESTION SECTION:
;example.com._report._dmarc.abuse.net. IN TXT

;; ANSWER SECTION:
example.com._report._dmarc.abuse.net. 3600 IN TXT "v=DMARC1\; p=none\; 
spam=plenty\;"

(The spam=plenty is a joke, but it doesn't hurt anything)

R's,
John
-- 
Regards,
John Levine, jo...@iecc.com, Primary Perpetrator of "The Internet for Dummies",
Please consider the environment before reading this e-mail. https://jl.ly
___
dmarc-discuss mailing list
dmarc-discuss@dmarc.org
http://www.dmarc.org/mailman/listinfo/dmarc-discuss

NOTE: Participating in this list means you agree to the DMARC Note Well terms 
(http://www.dmarc.org/note_well.html)

Re: [dmarc-discuss] A bit confused on the utility of a DNS record for DMARC external validation

[John Levine via dmarc-discuss]

In article  
you write:
>QUESTION ONE: How is it possible for me to continue to receive aggregate
>reports from domains that have no DMARC external validation for the
>receiving domain ?

Domains are cheap.  Buy some random domain like nottwo.com, publish a
suitable record at one.com._report._dmarc.nottwo.com, set up a mail
server somewhere for nottwo.com that forwards the mail to where you
really want it to go (a $5/mo vps is plenty) and have at it.

R's,
John
___
dmarc-discuss mailing list
dmarc-discuss@dmarc.org
http://www.dmarc.org/mailman/listinfo/dmarc-discuss

NOTE: Participating in this list means you agree to the DMARC Note Well terms 
(http://www.dmarc.org/note_well.html)

Re: [dmarc-discuss] What is the usefulness of choosing 'iodef' versus 'afrf" ?

[John Levine via dmarc-discuss]

In article <1512576134.2662.9.ca...@wemonitoremail.com> you write:
>On Wed, 2017-12-06 at 09:48 -0500, DMARC via dmarc-discuss wrote:
>> Is this an example where one standard as been publically accepted and the
>> competing standards are more or less deprecated in deployment ?

They're different applications so they use different schemas.  DMARC
reports don't describe incidents, and are unlike the stuff IODEF is
generally used for, phishing and DDoS.

There are plenty of applications that use iodef; start here:

http://siis.realmv6.org/implementations/

R's,
John


___
dmarc-discuss mailing list
dmarc-discuss@dmarc.org
http://www.dmarc.org/mailman/listinfo/dmarc-discuss

NOTE: Participating in this list means you agree to the DMARC Note Well terms 
(http://www.dmarc.org/note_well.html)

Re: [dmarc-discuss] Support for implementing dmarc filter in receiver's company/organisation

[John Levine via dmarc-discuss]

In article  you write:
>Although the domain-registrant end of DMARC is by-design easy to 
>implement, implementing the receiver-side in a sound fashion remains a 
>hard problem and therefore a rather specialist one. In general, only 
>large service providers and technology vendors are capable of retaining 
>that expertise at present.

Depending on the scale of your system, I wouldn't go quite that far.
With a scoring system like spamassassin it's pretty easy to use DMARC
cues as part of the score, although I agree it is also easy to use them
badly and lose mail that your users want.

R's,
John

>> Please note that this message may contain confidential information. If you 
>> have received this message by mistake, please
>inform the sender of the mistake, then delete the message from your system 
>without making, distributing or retaining any
>copies of it.

Too late.
___
dmarc-discuss mailing list
dmarc-discuss@dmarc.org
http://www.dmarc.org/mailman/listinfo/dmarc-discuss

NOTE: Participating in this list means you agree to the DMARC Note Well terms 
(http://www.dmarc.org/note_well.html)

Re: [dmarc-discuss] What would be a guesstimate to the DMARC report count for a 65k account enterprise ?

[John Levine via dmarc-discuss]

In article 

Re: [dmarc-discuss] 2 questions about evaluating DMARC reports -- recommendations ?

[John Levine via dmarc-discuss]

In article  
you write:
>   - QUESTION: what are the available appliances or tool sets for analyzing
>   DMARC reports, on-premise ?

I give away some scripts that read dmarc reports and put the interesting
bits in a database at https://www.taugh.com/rddmard

>   - QUESTION: Agari seems to be the only hosted player in the Federal
>   space. Are there others that perform DMARC reporting analysis ?

I agree that Dmarcian is worth a look.

R's,
John
___
dmarc-discuss mailing list
dmarc-discuss@dmarc.org
http://www.dmarc.org/mailman/listinfo/dmarc-discuss

NOTE: Participating in this list means you agree to the DMARC Note Well terms 
(http://www.dmarc.org/note_well.html)

Re: [dmarc-discuss] DKIM vulnerability overview

[John Levine via dmarc-discuss]

In article  
you write:
>Recently this article came to my attention:
>http://noxxi.de/research/breaking-dkim-on-purpose-and-by-chance.html
>
>It gives a nice overview of some of the vulnerabilties in the DKIM spec.
>I understand that this is mostly stuff which is in the spec already.

There is nothing whatsoever new in this article.  These are all topics
that have been discussed and debated ad nauseam over the past decade.

I suppose it wouldn't hurt to do double signing to prevent people from
adding extra From: or Subject: headers, but I also note that this
purported attack has been known for many years, nobody does it, and
there is little reason to think it would be effective.

R's,
John
___
dmarc-discuss mailing list
dmarc-discuss@dmarc.org
http://www.dmarc.org/mailman/listinfo/dmarc-discuss

NOTE: Participating in this list means you agree to the DMARC Note Well terms 
(http://www.dmarc.org/note_well.html)

Re: [dmarc-discuss] How to block fake forwarders?

[John Levine via dmarc-discuss]

In article <59de991d.29608.10e74...@webbed.pete.gmail.com> you write:
>2) I was under the impression that a "real" email server needs to be able to 
>both receive 
>(postmaster@) and send (MAILER-DAEMON@) administrative emails.

Yes, but only for the domains for which it handles real mail.  If you
want no mail sent or received by ds.org (as opposed to any other
domains you host) it is just fine to say that.

>(I realize I could munge it so the server sends as one of our other domains. 
>Somehow 
>that feels incorrect...

That is exactly correct.  I have a mail server called mail1.iecc.com which 
handles
mail for a zillion domains, but there is no mail to or from mail1.iecc.com so it
has SPF -all and a null MX.

R's,
John
___
dmarc-discuss mailing list
dmarc-discuss@dmarc.org
http://www.dmarc.org/mailman/listinfo/dmarc-discuss

NOTE: Participating in this list means you agree to the DMARC Note Well terms 
(http://www.dmarc.org/note_well.html)

Re: [dmarc-discuss] How to block fake forwarders?

[John Levine via dmarc-discuss]

In article <59dd1c2e.27060.b174...@webbed.pete.gmail.com> you write:
>Is there anything I can do to fix this?

I'd start by publishing an SPF record that just says "-all" rather
than what's in there now which says that there's all sorts of places
that real mail can come from.  A lot of places treat a plain -all as a
special case for no mail at all, as opposed to -all after other stuff
which means that you think these are the only places your mail can come
from but you're probably wrong.

If you don't expect inbound mailto ds.org, a null MX is also a good
idea.  You can still collect reports via your dmarc record.

You'll get less blowback, but it'll never go away.  I also have some
ancient domains (try iecc.cambridge.ma.us) and the spam never stops.

R's,
John
___
dmarc-discuss mailing list
dmarc-discuss@dmarc.org
http://www.dmarc.org/mailman/listinfo/dmarc-discuss

NOTE: Participating in this list means you agree to the DMARC Note Well terms 
(http://www.dmarc.org/note_well.html)

Re: [dmarc-discuss] DMARC and vanity domains

[John Levine via dmarc-discuss]

>Am 25.08.2017 um 19:22 schrieb Marc Luescher via dmarc-discuss:
>> I did not find any guideline how to do this.
>
>https://www.m3aawg.org/documents/en/m3aawg-protecting-parked-domains-best-common-practices

Assuming you mean domains that neither send nor receive e-mail, the M3AAWG 
document
is the best advice you'll find.  Don't forget the null MX records to tell 
people that
you don't receive mail either.

By the way, "vanity domain" isn't a good term for a domain that sends
no mail.  I host plenty of vanity domains that have a single user that
sends lots of mail.

R's,
John
___
dmarc-discuss mailing list
dmarc-discuss@dmarc.org
http://www.dmarc.org/mailman/listinfo/dmarc-discuss

NOTE: Participating in this list means you agree to the DMARC Note Well terms 
(http://www.dmarc.org/note_well.html)

Re: [dmarc-discuss] Anything to be done about DMARC failures caused by internal Microsoft forwards?

[John Levine via dmarc-discuss]

In article  you write:
>Can we do anything to prevent messages such as this one from bouncing
>when we turn on p=reject?

Probably not.

Perhaps you could back up and tell us what problem you expect to solve
by turning on p=reject.  Unless you are a target of an unusual amount
of phishing or malicious forgery, p=reject often causes more problems
than it solves.

R's,
John
___
dmarc-discuss mailing list
dmarc-discuss@dmarc.org
http://www.dmarc.org/mailman/listinfo/dmarc-discuss

NOTE: Participating in this list means you agree to the DMARC Note Well terms 
(http://www.dmarc.org/note_well.html)

Re: [dmarc-discuss] Netscape.net?

[John Levine via dmarc-discuss]

In article  
you write:
>
>One of our mailing list members, with a netscape.net email address, is
>getting DMARC bounces. That domain is set to p=none.

That hasn't been the case for quite a while.

$ dig _dmarc.netscape.net txt

;; QUESTION SECTION:
;_dmarc.netscape.net.   IN  TXT

;; ANSWER SECTION:
_dmarc.netscape.net.60  IN  TXT "v=DMARC1; p=reject; fo=1; 
pct=100; ri=3600; rua=mailto:a...@rua.agari.com; ruf=mailto:a...@ruf.agari.com;

R's,
John
___
dmarc-discuss mailing list
dmarc-discuss@dmarc.org
http://www.dmarc.org/mailman/listinfo/dmarc-discuss

NOTE: Participating in this list means you agree to the DMARC Note Well terms 
(http://www.dmarc.org/note_well.html)

Re: [dmarc-discuss] Why do I receive RUAs for emails that align?

[John Levine via dmarc-discuss]

>I guess I'm now more inclined to remove the rua= stanza as I don't
>manage user accounts and am really only interested in the failures.

I concur with Roland.  Looking at my failure reports, I see some from
Hotmail and Linkedin and beyond that a few from Chinese and Russian
ISPs generally reporting random spam that happened to randomly fake my
domain.  The Hotmail reports are redacted so they are certainly better
than nothing but not that much better.  They will not give you anything
like a comprehensive view of where your DMARC failures are.

The aggregate reports tell you about both success and failures, so put
them in a database and query for stats about the failures.  This is
not, as they say, rocket science.

R's,
John
___
dmarc-discuss mailing list
dmarc-discuss@dmarc.org
http://www.dmarc.org/mailman/listinfo/dmarc-discuss

NOTE: Participating in this list means you agree to the DMARC Note Well terms 
(http://www.dmarc.org/note_well.html)

Re: [dmarc-discuss] Why do I receive RUAs for emails that align?

[John Levine via dmarc-discuss]

In article  
you write:
>Hello,
>
>I'm trying to limit RUA/RUFs to legitimate emails that need eyeballs.
>
>To that end, I'm scratching my head as to why I get RUAs that clearly align.

That's how it works.  See section 7.2 of RFC 7489.  Aggregate reports
tell you about all the mail a system got that has your domain on the
From: line.

Everyone I know automatically parses the aggregate reports and puts
the info in a database so they can query it about whatever is of
interest.

Here's some scripts I give away that do the parse and put in a database part.

http://www.taugh.com/rddmarc/

R's,
John
___
dmarc-discuss mailing list
dmarc-discuss@dmarc.org
http://www.dmarc.org/mailman/listinfo/dmarc-discuss

NOTE: Participating in this list means you agree to the DMARC Note Well terms 
(http://www.dmarc.org/note_well.html)

Re: [dmarc-discuss] DMARC forensic reporting options

[John Levine via dmarc-discuss]

>Any comments on this?

I doubt it would make any difference.  People don't send reports
because they don't want to send reports, not because the reports are
too big.  As someone else noted, the privacy issues are just as bad
with the headers.

R's,
John
___
dmarc-discuss mailing list
dmarc-discuss@dmarc.org
http://www.dmarc.org/mailman/listinfo/dmarc-discuss

NOTE: Participating in this list means you agree to the DMARC Note Well terms 
(http://www.dmarc.org/note_well.html)

Re: [dmarc-discuss] gmail's DMARC check doesn't respect subdomain policy

[John Levine via dmarc-discuss]

>Domain a.prnk.cz doesnt have DMARC record. Domain prnk.cz has a DMARC 
>record that contains p=reject and sp=none. It looks like gmail doesn't 
>respect subdomain policy and rejects the email even when sp=none.

Looks to me like Google is doing exactly what the DMARC spec says they
should do.

This would be a good time to reread RFC 7489, particularly section
6.6.3, and very particularly numbered item 3 in that section.

R's,
John
___
dmarc-discuss mailing list
dmarc-discuss@dmarc.org
http://www.dmarc.org/mailman/listinfo/dmarc-discuss

NOTE: Participating in this list means you agree to the DMARC Note Well terms 
(http://www.dmarc.org/note_well.html)

Re: [dmarc-discuss] FBL via DMARC?

[John Levine via dmarc-discuss]

>> But see https://datatracker.ietf.org/doc/draft-levine-herkula-oneclick/

>Is this really a good idea? Spammers will add this new header as they added
>List-Unsubscribe headers as well and you will kindly validate the spammed
>email address if a user marks it as junk.

There are much, much, easier ways to validate recipient addresses such
as web bugs, which spammers could use if they cared, which they
haven't for at least the past decade.  Or for that matter, they could
use the existing List-Unsubscribe, which has been around since 1998.

We address this and other stuff in the Security Considerations section
in the draft.

R's,
John

PS: This really has nothing to do with DMARC.  The discussions
about this draft have been on the IETF dispatch mailing list.
___
dmarc-discuss mailing list
dmarc-discuss@dmarc.org
http://www.dmarc.org/mailman/listinfo/dmarc-discuss

NOTE: Participating in this list means you agree to the DMARC Note Well terms 
(http://www.dmarc.org/note_well.html)

Re: [dmarc-discuss] Getting to reject, was :Re: FortiNet’s FortiMail DMARC implementation

[John Levine via dmarc-discuss]

>p= none is not just because people don't care.

What he said.  p=none lets you collect reports and decide what to do.
In my case, the reports have told me that for all but one of the
domains I manage*, nobody is forging them enough to be worth further
DMARC pain.

I would suggest a note saying that Fortinet's implementation is known
to be fatally buggy.

R's,
John

* - the one is abuse.net, could probably do p=quarantine since nobody's
supposed to send mail from abuse.net addresses through lists.


___
dmarc-discuss mailing list
dmarc-discuss@dmarc.org
http://www.dmarc.org/mailman/listinfo/dmarc-discuss

NOTE: Participating in this list means you agree to the DMARC Note Well terms 
(http://www.dmarc.org/note_well.html)

Re: [dmarc-discuss] Beware of the size limit in DMARC URIs

[John Levine via dmarc-discuss]

>There's another question to raise in the IETF working group - do we need
>to re-consider the use of HTTPS as an alternative transport for reports?
>(Background: HTTP was in the original spec, but hadn't been implemented,
>and so was dropped several years ago.)
>
>If we're running into the common size limits on email messages for
>reports at the largest senders/receivers today, what should we be
>planning for in five years? In ten? Maybe it's time to re-establish an
>alternate channel in the spec, so it will be ready when we need it.

It's a poor idea to put stuff into a spec if nobody's planning to
implement it, because that generally results in a spec that doesn't
work when someone tries later.  The original http language was
hopelessly broken, so I offered something different that I think
would have worked, but nobody ever tested.

So if DMARC reports are getting too big, I'd be happy to resuscitate
the http language in a short draft to update RFC 7489, but only if
there are a few people who plan to implement each side of it so we can
be sure that it works.

Technically it's really simple, a single HTTP PUT operation which
is not as common as GET or POST, but should be supported by every
web server, and automagically provides for compression and duplicate
report elimination.

R's,
John

___
dmarc-discuss mailing list
dmarc-discuss@dmarc.org
http://www.dmarc.org/mailman/listinfo/dmarc-discuss

NOTE: Participating in this list means you agree to the DMARC Note Well terms 
(http://www.dmarc.org/note_well.html)

Re: [dmarc-discuss] dmarc.org breaks dkim & dmarc

[John Levine via dmarc-discuss]

In article <10d366e813d75805a35b93d9c9b7f...@junc.eu>,
Benny Pedersen via dmarc-discuss   wrote:
>On 2016-10-04 17:20, Franck Martin wrote:
>> I'm not sure what is the issue here? Mailing lists break DKIM by
>> design.
>
>bad designed on thiese maillist then its not dkim/dmarc fails

This is phenomenally unhelpful.

Mailing lists were in active use for at least 40 years before anyone
thought of DMARC.  When consumer mail systems (notably AOL and Yahoo)
turned on DMARC, they knew exactly what collateral damage it would
cause and who it would hurt.

We've been through this a dozen times, and attempts to blame the
victim only show a failure to understand the way that mail works.

With any luck ARC will mitigate some, not all, of the damage.  We now
return you to the usual arguments.

R's,
John
___
dmarc-discuss mailing list
dmarc-discuss@dmarc.org
http://www.dmarc.org/mailman/listinfo/dmarc-discuss

NOTE: Participating in this list means you agree to the DMARC Note Well terms 
(http://www.dmarc.org/note_well.html)

Re: [dmarc-discuss] DMARC where mail is never sent

[John Levine via dmarc-discuss]

>> Does it make sense to publish a DMARC record to signal that a host
>> should never send email? Can said record be published without an
>> accompanying DKIM record?
>
>See  
>http://www.m3aawg.org/documents/en/m3aawg-protecting-parked-domains-best-common-practices

Quite right.  While you're at it, assuming the domain doesn't receive mail 
either,
also publish a null MX.

R's,
John
___
dmarc-discuss mailing list
dmarc-discuss@dmarc.org
http://www.dmarc.org/mailman/listinfo/dmarc-discuss

NOTE: Participating in this list means you agree to the DMARC Note Well terms 
(http://www.dmarc.org/note_well.html)

Re: [dmarc-discuss] Deliverability of DMARC reports

[John Levine via dmarc-discuss]

>There's a semi-related issue I'm seeing. A number of domains have used
>addresses @dmarc.org for their aggregate reports, and some report
>generators have not implemented cross-domain reporting authorization
>checks. This volume pales in comparison to the volume of spam directed
>at the same reporting address, but is anybody else seeing this and
>thinks it's a problem?

I think you're just observing the truism that no good deed goes
unpunished.  Perhaps you could treat it as lead generation, collect
the reports and offer to sell advice to both the people sending them
and the ones reported on to improve their DMARC setup.


>> Do postmasters risk bad reputation if they continue to send DMARC reports?
>
>Another question a friendly large mailbox provider could possibly answer
>for us... Has anybody asked Spamhaus to see if this is on their radar?

I'm reasonably sure it is not.

>That inspires another question -- has anybody seen a real-world abuse or
>DoS involving DMARC reporting? There's a potential there, and I believe
>we identified it in the security considerations in RFC7489, but is there
>any indication this is a problem that needs more attention?

Unless a really gigantic provider pointed their reports at you, it
seems unlikely.  I've been collecting reports for a dozen domains
since 2012 and the total number of aggregate reports since I've
started is less than 100,000, failure reports less than 60,000.

R's,
John
___
dmarc-discuss mailing list
dmarc-discuss@dmarc.org
http://www.dmarc.org/mailman/listinfo/dmarc-discuss

NOTE: Participating in this list means you agree to the DMARC Note Well terms 
(http://www.dmarc.org/note_well.html)

Re: [dmarc-discuss] introduction to the list-virtual server & mailman questions

[John Levine via dmarc-discuss]

>ARC purpose is to say when DMARC fail and the email should be rejected that
>it is ok to let it through. As such there is no scale problem and anyone
>can do it.

ARC provides no protection against replay attacks, in particular,
against taking a set of ARC headers from a benign message and sticking
them on malware or spam.  (This isn't saying it's misdesigned, just
that it does what it does.)

That means that it only makes sense to evaluate ARC headers on mail
from hosts that you believe are generally trustworthy.  Large mail
systems have enough mail flow that they usually already have a pretty
good idea who's trustworthy, small mail systems don't.

I have a database that has logged every single connection to my MTA
since 2008, and which mail was treated how, but that's still nowhere
near enough to provide useful reputation info about sources other than
ones that are so so large that I can just whitelist them anyway.
Scott and I aren't saying the code's too hard to write, we can code
anything we want to.  We don't have the data.

R's,
John
___
dmarc-discuss mailing list
dmarc-discuss@dmarc.org
http://www.dmarc.org/mailman/listinfo/dmarc-discuss

NOTE: Participating in this list means you agree to the DMARC Note Well terms 
(http://www.dmarc.org/note_well.html)

Re: [dmarc-discuss] introduction to the list-virtual server & mailman questions

[John Levine via dmarc-discuss]

>Smells like:
>
>From: Paypal Security secur...@paypal.com 
>
>Not sure it is a good idea.

It's a terrible idea.  Too bad some ill-designed security scheme
forces people to do stuff like that.

R's,
John
___
dmarc-discuss mailing list
dmarc-discuss@dmarc.org
http://www.dmarc.org/mailman/listinfo/dmarc-discuss

NOTE: Participating in this list means you agree to the DMARC Note Well terms 
(http://www.dmarc.org/note_well.html)

Re: [dmarc-discuss] introduction to the list-virtual server & mailman questions

[John Levine via dmarc-discuss]

>dmarc.fail is an interesting approach, however the spam filters aren't the 
>concern that's
>being raised here, user education is. Teach people that
>my.fri...@real.domain.some-unfamiliar-stuff is a reasonable email address to 
>receive
>email from (vs. teaching them to treat that as extremely suspicious) by 
>periodically
>having legitimate email arrive that way (and preferentially from 
>heavily-phished domains)
>and you incrementally help phishers.

How is this different from everyone's favorite alleged mailing list
solution?

 From: Foo list on behalf of Jane Smith 

R's,
John

PS: well, other than it's a little more explicit about where the
responsibility lies
___
dmarc-discuss mailing list
dmarc-discuss@dmarc.org
http://www.dmarc.org/mailman/listinfo/dmarc-discuss

NOTE: Participating in this list means you agree to the DMARC Note Well terms 
(http://www.dmarc.org/note_well.html)

Re: [dmarc-discuss] introduction to the list-virtual server & mailman questions

[John Levine via dmarc-discuss]

>I'd prefer:
>
>From: Foo list [Jane Smith] 
>CC: Jane Smith 

Given that most MUAs these days don't show the e-mail address at all,
it's hard to see why that would be better.

>- violating the principle of least astonishment[1] (wait, the list operator 
>caused my
>private reply to be routed through his mail-server?)

You must know different users than I do.  Most of them have no idea
how their mail gets from them to their correspondents, and I don't
recall any of them asking unless something screwed up and it got lost.
A great deal of mail to various domains ends up at gmail, and they
don't seem to have any trouble with that.  Data point: I've been doing
the dmail.fail rewrite for the better part of a year, I've had exactly
one user ask what it was, and when I explained it was to get around
some overeager filtering at large ISPs, they thought that was fine.

R's,
John

PS:

>1: Reply-To: appears to have become a third rail, I won't touch it.

Oh, it's been a point of religious controversy for at least 20 years.
I wouldn't touch it either, other than to note that adding a reply-to
as a workaround to From: header workarounds rarely works the way
you expect it to.
___
dmarc-discuss mailing list
dmarc-discuss@dmarc.org
http://www.dmarc.org/mailman/listinfo/dmarc-discuss

NOTE: Participating in this list means you agree to the DMARC Note Well terms 
(http://www.dmarc.org/note_well.html)

Re: [dmarc-discuss] introduction to the list-virtual server & mailman questions

[John Levine via dmarc-discuss]

>Not to mention this is also a privacy issue. Now the owner of dmarc.fail
>has visibility on some traffic he/she should not see.

Oh, come on.  The owner of dmarc.fail is me, and I assign the addresses
to mail that goes through my own web server.

R's,
John
___
dmarc-discuss mailing list
dmarc-discuss@dmarc.org
http://www.dmarc.org/mailman/listinfo/dmarc-discuss

NOTE: Participating in this list means you agree to the DMARC Note Well terms 
(http://www.dmarc.org/note_well.html)

Re: [dmarc-discuss] introduction to the list-virtual server & mailman questions

[John Levine via dmarc-discuss]

In article 

Re: [dmarc-discuss] introduction to the list-virtual server & mailman questions

[John Levine via dmarc-discuss]

In article <2049568.4HsipfqAXp@kitterma-e6430> you write:
>To start with, you'll have to explain why receivers should trust a sender to 
>not lie about where they got the mail from in an ARC header field if they 
>don't 
>already trust the sender.

If you're suggesting that ARC is only useful when you already trust
the forwarding party, and if you trust the forwarding party, why do
you need ARC, yeah, that's been pointed out before.

The best explanation I've seen was from someone at Google who said
that they often see well behaved lists suddenly start to send spam
when a spambot happens to send mail that fakes a subscriber's return
address.  ARC would make it somewhat easier to tell when that happens.

R's,
John
___
dmarc-discuss mailing list
dmarc-discuss@dmarc.org
http://www.dmarc.org/mailman/listinfo/dmarc-discuss

NOTE: Participating in this list means you agree to the DMARC Note Well terms 
(http://www.dmarc.org/note_well.html)

Re: [dmarc-discuss] rddmarc & comcast reports

[John Levine via dmarc-discuss]

>I noticed last week rddmarc fail to read aggregated reports from Comcast.
>They send an unusual Content-Type: application-x-gzip;

The most recent Comcast reports I have are from September, and they have
the same wrong content type.  It should be 

 Content-Type: application/gzip; ... whatever ...

(That's why I wrote RFC 6713.)

While our pals at Comcast are checking their header writing code, they
might also want to check why there aren't more recent reports.

R's,
John
___
dmarc-discuss mailing list
dmarc-discuss@dmarc.org
http://www.dmarc.org/mailman/listinfo/dmarc-discuss

NOTE: Participating in this list means you agree to the DMARC Note Well terms 
(http://www.dmarc.org/note_well.html)

Re: [dmarc-discuss] dmarc gogole attachments seen as executable

[John Levine via dmarc-discuss]

As is standard settings in lot of AV mailscanners to not allow 
attachments as example with a .com in it.
Therefore it is not a good idea that google is sending attachments DMARC 
with these filename !google.com!domain.comgjdsadg6777.zip   bacause of 
the .com names in it these are rejected in lot of AVscanners standard 
server settings for them, see also directadmin forum for that rejects 
frozen mail queu and so on.
Please dont put a dotcom in the filenames attachment.

The format of DMARC reports has been unchanged for several years, and
there is software that expects the filenames the way they are now.

Honestly, any AV scanner that depends on the filename is pretty
useless, since malware can and does trivially avoid it by using a
different name.  I'd suggest first arranging to send your DMARC
reports to an address with no content filters so your automated
anaylsis software can handle it, and look for more modern AV software.

R's,
John
___
dmarc-discuss mailing list
dmarc-discuss@dmarc.org
http://www.dmarc.org/mailman/listinfo/dmarc-discuss

NOTE: Participating in this list means you agree to the DMARC Note Well terms 
(http://www.dmarc.org/note_well.html)

Re: [dmarc-discuss] dmarc gogole attachments seen as executable

[John Levine via dmarc-discuss]

I'd disagree about content filtering completely. There are some file 
extensions that are inherently dangerous in the Windows world and .COM 
is one of them.

If your AV depends on the filenames in the attachment headers, you've
already lost.  It needs to look at the attachment contents to see what
the files are.  COM aren't as easy to recognize as EXE, but it's not
hard.

And what Al said -- if your DMARC reports are going anywhere near
something that can be fooled into running attachments, there's
something seriously suboptimal in your mail setup.  The only
attachments in DMARC reports are the ARF message copy in failure
reports and the compressed XML in aggregate reports.

R's,
John
___
dmarc-discuss mailing list
dmarc-discuss@dmarc.org
http://www.dmarc.org/mailman/listinfo/dmarc-discuss

NOTE: Participating in this list means you agree to the DMARC Note Well terms 
(http://www.dmarc.org/note_well.html)

Re: [dmarc-discuss] Still having problems with third-party sending

[John Levine via dmarc-discuss]

I'm trying to improve my understanding of the third-party sender problem when, 
for reasons
technical and political, you want to maintain a distance between 
organizational domain and
the working domain. 

DKIM and DMARC and for that matter SPF are not designed to distinguish
among authorized senders for the same domain.  If you want to manage
multiple mail streams independently, use subdomains.

- From addresses should look like: x...@intelli-shop.com . 

Use something like x...@email.intelli-shop.com.  They can delegate
email.intelli-shop.com to you, then you can set up all of the DKIM and
SPF and DMARC stuff for that subdomain any way you want.  If you look
at the mail coming from large brands, you'll see that's pretty common.

DKIM selectors are for key management, not to create multiple mail
streams visible to outsiders.  You're not the first to have that
misunderstanding but I don't know how to make it any clearer in the
documentation.

R's,
John
___
dmarc-discuss mailing list
dmarc-discuss@dmarc.org
http://www.dmarc.org/mailman/listinfo/dmarc-discuss

NOTE: Participating in this list means you agree to the DMARC Note Well terms 
(http://www.dmarc.org/note_well.html)

Re: [dmarc-discuss] am not getting any rua reports for a domain

[John Levine via dmarc-discuss]

_dmarc.sb.mumble.com. 2947 INTXTv=DMARC1\; 
p=none\;rua=mailto:sbmumblecom_...@my.mailservice.com\; fo=0\; adkim=r\; 
aspf=r\;sp=none

If you want a real answer, please give us the real domain names.

You're already asking for DMARC reports from total strangers so it's
not like there are any big secrets here.

R's,
John
___
dmarc-discuss mailing list
dmarc-discuss@dmarc.org
http://www.dmarc.org/mailman/listinfo/dmarc-discuss

NOTE: Participating in this list means you agree to the DMARC Note Well terms 
(http://www.dmarc.org/note_well.html)

Re: [dmarc-discuss] exim rejecting gmail DMARC reports

[John Levine via dmarc-discuss]

This message has been rejected because it has
potentially executable content google.com!domain-redacted.com
This form of attachment has been used by
recent viruses or other malware.
If you meant to send this file then please
package it up as a zip file and resend it.

Any way around this? In the message above, I replaced the actual domain
with domain-redacted

Your mail filters are broken.  Google's DMARC reports are sent as an
attached zip file which contains a single XML file.  Your mail filters
are finding the string .com in the middle of the ZIP file's TOC (not
even at the end of the filename) and wrongly assuming that means a DOS
executable.

Just how old is your copy of exim, anyway?

R's,
John


___
dmarc-discuss mailing list
dmarc-discuss@dmarc.org
http://www.dmarc.org/mailman/listinfo/dmarc-discuss

NOTE: Participating in this list means you agree to the DMARC Note Well terms 
(http://www.dmarc.org/note_well.html)

Re: [dmarc-discuss] amazon.de fail

[John Levine via dmarc-discuss]

In article 20150616080608.horde.np0fbkrfk-jumt5krom4...@andreasschulze.de you 
write:
someone from amazon Germany may be interested.
Again: I guess it's a legit message from amazon, otherwise let me know ...

It looks fine.  How does your code pass the DKIM validation results to the 
DMARC code?




Authentication-Results: idvmailin13.datevnet.de;
   dkim=pass (1024-bit key; unprotected) header.d=amazonses.com  
header.i=@amazonses.com header.b=IGahw/4Y
Authentication-Results: idvmailin13.datevnet.de;
   spf=pass  
smtp.mailfrom=201506160039204c745a2b7a8d4cd89e6e312cb96417e9-cuo19kbgo1...@bounces.amazon.com
smtp.helo=a0-79.smtp-out.eu-west-1.amazonses.com

I have never seen an A-R implementation that added multiple headers.
Everyone else puts all the results in one header, separated by
semicolons.  If your code reads the A-R header, that's likely the
problem, it only expects one A-R header so it only looks at the first
one, which in this case happens not to include a result that makes
DMARC happy.

R's,
John
___
dmarc-discuss mailing list
dmarc-discuss@dmarc.org
http://www.dmarc.org/mailman/listinfo/dmarc-discuss

NOTE: Participating in this list means you agree to the DMARC Note Well terms 
(http://www.dmarc.org/note_well.html)

Re: [dmarc-discuss] amazon.de fail

[John Levine via dmarc-discuss]

Would be good to hear from Murray if this is the intended use-case for 
OpenDMARC. In general I know OpenDMARC simply as an A-R header parser.
So my assumptions could not be completely wrong...

I call the libraries directly, so in my implementation nothing parses A-R 
headers at all.

R's,
John
___
dmarc-discuss mailing list
dmarc-discuss@dmarc.org
http://www.dmarc.org/mailman/listinfo/dmarc-discuss

NOTE: Participating in this list means you agree to the DMARC Note Well terms 
(http://www.dmarc.org/note_well.html)

Re: [dmarc-discuss] probably bug in OpenDMARCs AR-header parser

[John Levine via dmarc-discuss]

It looks like the OpenDMARCs AR-header parser fail to recognise the  
AR-header generated by OpenDKIM.

It must be more than that.  I also use both opendkim and opendmarc, and multiple
DKIM signatures are not a problem:

Authentication-Results: iecc.com; spf=neutral spf.mailfrom=jo...@taugh.com 
spf.helo=spmpdv02.ieee.org;
dkim=pass header.d=iecc.com header.b=I8oYyArI; dkim=pass 
header.d=taugh.com header.b=YRY5Bjv7;
dmarc=pass header.from=taugh.com policy=none

I do run them in the same process and pass the DKIM results to DMARC
via API calls.  If you ever want to implement p=reject that seems
unavaoidable.

R's,
John
___
dmarc-discuss mailing list
dmarc-discuss@dmarc.org
http://www.dmarc.org/mailman/listinfo/dmarc-discuss

NOTE: Participating in this list means you agree to the DMARC Note Well terms 
(http://www.dmarc.org/note_well.html)

Re: [dmarc-discuss] dmarc and delegated zones

[John Levine via dmarc-discuss]

If I understand you correctly, even though zones don't matter to how I 
create the records, the zones could be a useful tool for me delegating 
management of the records. If I have one set of records for example.com 
in one organization and another set of exhibit records in New 
Jersey.example.com managed by my organization then I can manage the 
records independent of the parent organization.

If that's the way your name servers are set up, sure.  There's no
general answer about what's easier since it depends on how your DNS
provisioning is set up.

Are there any collisions between the DMARC records configuritions in the 
parent domain versus a subdomain that I need to worry about?

There shouldn't be.  The point of using the _dmarc prefix name is that it
shouldn't conflict with anything else.

my interpretation of what I've read leads me to believe I'm better off 
keeping all of the header addresses in the same domain and using a 
reply-to to direct responses to a real human instead of trying to make 
the from: address the humans address.

Again, it depends on how your system is set up.  Assuming you control
the inbound MTAs for your domain, you should be able to route the incoming
replies to the From: addresses wherever you need to.

R's,
John
___
dmarc-discuss mailing list
dmarc-discuss@dmarc.org
http://www.dmarc.org/mailman/listinfo/dmarc-discuss

NOTE: Participating in this list means you agree to the DMARC Note Well terms 
(http://www.dmarc.org/note_well.html)

Re: [dmarc-discuss] dmarc and delegated zones

[John Levine via dmarc-discuss]

Can a delegated zone have its own DKIM, SPF and DMARC records?

There's no way to answer this question, because DKIM, SPF, and DMARC
have no relationship whatsoever to zone delegations.  They're defined
in terms of domain names, and zone cuts don't matter.

You can put DKIM, SPF, and DMARC records at any domain name.  SPF
looks up whatever domain name is in the envelope bounce address, DKIM
looks up whatever domain name is in the d= field of the DKIM signature,
and DMARC usually looks up the domain in the From: address.

The only exception is there is a hack in DMARC such that if the lookup
for the DMARC record doesn't find anything, it can look for an
organizational domain name, typically using the Mozilla Public
Suffix List.  For example, if the From: address were
sa...@newjersey.example.com and there were no DMARC record at
_dmarc.newjersey.example.com, it could also look for
_dmarc.example.com.  The organizational domain is chosen by counting
dots in the name, not by looking at zone cuts.

R's,
John

___
dmarc-discuss mailing list
dmarc-discuss@dmarc.org
http://www.dmarc.org/mailman/listinfo/dmarc-discuss

NOTE: Participating in this list means you agree to the DMARC Note Well terms 
(http://www.dmarc.org/note_well.html)

Re: [dmarc-discuss] Aligning non-identical domain names

[John Levine via dmarc-discuss]

You will not find me disagreeing with you, although I might use different
words than 'configuration issue'. However, I'm pretty sure we're not the
only folks in similar situations (consider, from an older thread,
netscape.com / aol.com addresses). ...

This is a tradeoff between senders and receivers.  You're saying that
for whatever reason, you're not prepared to generate mail that passes
DMARC as currently defined, so you want receivers to do more work to
work around that.

I'm certainly not opposed to changes to DMARC to make it handle
situations where it fails now (see my strawman at
draft-levine-may-forward-01 to better support mailing lists and the
like) but the justification here doesn't seem very strong.

R's,
John
___
dmarc-discuss mailing list
dmarc-discuss@dmarc.org
http://www.dmarc.org/mailman/listinfo/dmarc-discuss

NOTE: Participating in this list means you agree to the DMARC Note Well terms 
(http://www.dmarc.org/note_well.html)

Re: [dmarc-discuss] Aligning non-identical domain names

[John Levine via dmarc-discuss]

Some of my C*O level users, however, are complaining about issues sending
email via mobile devices, because they're sent via gateways that don't DKIM
sign the mail with livingsocial.com identifiers. 

There have been some proposals for extra domains for DKIM signatures, such
as the ones in RFC 6541, but they haven't provoked much interest.

This sounds like a configuration issue with your mobile users, not a DMARC
problem.

R's,
John


___
dmarc-discuss mailing list
dmarc-discuss@dmarc.org
http://www.dmarc.org/mailman/listinfo/dmarc-discuss

NOTE: Participating in this list means you agree to the DMARC Note Well terms 
(http://www.dmarc.org/note_well.html)

Re: [dmarc-discuss] Amazon email rejected by OpenDMARC but SPF DKIM are OK

[John Levine via dmarc-discuss]

   Authentication-Results: icecube.pnzone.net; dmarc=fail 
header.from=amazon.fr
   Authentication-Results: icecube.pnzone.net; dkim=pass
 reason=1024-bit key; unprotected key
 header.d=amazonses.com header.i=@amazonses.com header.b=BOrJMGL0;
 dkim-adsp=pass; dkim-atps=neutral

The only strange thing with this email is that it contains a double 
DKIM-Signature, the second one appearing just after the first one:

The Authentication-Results header doesn't mention the second DKIM signature,
and that's the one that matters for DMARC since it's the one with d=amazon.fr
to match from From: address.

Can you check the message to see if that signature is in fact good?  If it is,
you've probably found a bug.  I also use opendmarc and as I recall, it does
the right thing with multiple DKIM signatures so long as your MTA gives it all
the signatures. I'd start by checking the code in the MTA to be sure it does
that.

R's,
John
___
dmarc-discuss mailing list
dmarc-discuss@dmarc.org
http://www.dmarc.org/mailman/listinfo/dmarc-discuss

NOTE: Participating in this list means you agree to the DMARC Note Well terms 
(http://www.dmarc.org/note_well.html)

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

[John Levine via dmarc-discuss]

I don't understand what fo=1 is supposed to mean.  If there's no SPF
record at all, are you supposed to generate a report?  If there's no
DKIM signature at all, same question?  Of if there are DKIM signatures,
but none of them have a d= that matches the From: address?

My reading of the draft says yes to all three. 

The ambiguity for me is between SPF or DKIM failed and no SPF or DKIM
at all.  As I read it, it probably means failure, but maybe it means
something else.

___
dmarc-discuss mailing list
dmarc-discuss@dmarc.org
http://www.dmarc.org/mailman/listinfo/dmarc-discuss

NOTE: Participating in this list means you agree to the DMARC Note Well terms 
(http://www.dmarc.org/note_well.html)

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

[John Levine via dmarc-discuss]

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.

I don't understand what fo=1 is supposed to mean.  If there's no SPF
record at all, are you supposed to generate a report?  If there's no
DKIM signature at all, same question?  Of if there are DKIM signatures,
but none of them have a d= that matches the From: address?

R's,
John
___
dmarc-discuss mailing list
dmarc-discuss@dmarc.org
http://www.dmarc.org/mailman/listinfo/dmarc-discuss

NOTE: Participating in this list means you agree to the DMARC Note Well terms 
(http://www.dmarc.org/note_well.html)

Re: [dmarc-discuss] DMARC and mailing lists

[John Levine via dmarc-discuss]

I understand you may not have budgeted upgrades, ...

You know, it's kind of Orwellian to redefine upgrade to mean ugly
hack to work around damage caused by outsourcing the costs of security
problems of large entities with enormous market power.

Really, we understand why some providers weighed the costs and decided
to do something that shafted mailing lists and a bunch of other mail
operators.  But it would make the conversation a lot more honest and
productive if you admitted it, rather than trying to pretend that
decades of productive mail usage somehow became wrong because DMARC
doesn't happen to be able to describe it.

R's,
John
___
dmarc-discuss mailing list
dmarc-discuss@dmarc.org
http://www.dmarc.org/mailman/listinfo/dmarc-discuss

NOTE: Participating in this list means you agree to the DMARC Note Well terms 
(http://www.dmarc.org/note_well.html)

Re: [dmarc-discuss] DMARC and mailing lists

[John Levine via dmarc-discuss]

Some on this list will argue that update is a wrong word, though.

I would certainly agree with that.

There's a summary of all the mitigation techniques I know here:

http://wiki.asrg.sp.am/wiki/Mitigating_DMARC_damage_to_third_party_mail

If I've missed any, drop my a line and I'll send you a password so you
can edit the wiki.

On my lists, I'm currently rewriting stuff from DMARC'ed domains to
use forwarding addresses.  So if a list message is from, say,

 From: Marissa mme...@yahoo.com

It rewrites it to:

 From: Marissa mme...@yahoo.com.dmarc.fail

It locally arranges for that address to forward back to the original
one for a few days, and adds an appropriate DKIM signatures.  It was
all surprisingly easy to do, about 100 lines of python and perl.

R's,
John
___
dmarc-discuss mailing list
dmarc-discuss@dmarc.org
http://www.dmarc.org/mailman/listinfo/dmarc-discuss

NOTE: Participating in this list means you agree to the DMARC Note Well terms 
(http://www.dmarc.org/note_well.html)

Re: [dmarc-discuss] Unauthenticated emails being delivered to Google

[John Levine via dmarc-discuss]

In article 2dac908dcf71d142afbfd168ac96f9186e8bf...@sw720mbpx065.visa.com you 
write:
-=-=-=-=-=-
-=-=-=-=-=-

Has anyone experienced unauthenticated emails being delivered to Google 
recipients despite having a DMARC policy
(quarantine or reject) in place?

Sure.  That's the way Gmail users get their mailing list mail, by
hitting not spam enough to counterbalance the default DMARC action.

R's,
John
___
dmarc-discuss mailing list
dmarc-discuss@dmarc.org
http://www.dmarc.org/mailman/listinfo/dmarc-discuss

NOTE: Participating in this list means you agree to the DMARC Note Well terms 
(http://www.dmarc.org/note_well.html)

Re: [dmarc-discuss] Unauthenticated emails being delivered to Google

[John Levine via dmarc-discuss]

In article 53dad497.4070...@dcrocker.net you write:
On 7/31/2014 4:37 PM, Steve Atkins via dmarc-discuss wrote:
 If you're, for example, a major financial institution there are a couple of 
 things you could do. One would be to
talk to Google and others to special case mail from your domain. Longer term, 
you could help with an
alternative/extension to DMARC that is suitable solely for high-value 
transactional email, one that isn't
self-published and so open to misuse (that would likely involve third-party 
managed whitelists with entry to them
controlled by industry-specific or governmental groups).

Yup.  See RFC 5518.

R's,
John
___
dmarc-discuss mailing list
dmarc-discuss@dmarc.org
http://www.dmarc.org/mailman/listinfo/dmarc-discuss

NOTE: Participating in this list means you agree to the DMARC Note Well terms 
(http://www.dmarc.org/note_well.html)

Re: [dmarc-discuss] Postini rejected by Google

[John Levine via dmarc-discuss]

Messages affected seem to be forwards by Postini to Google.

In my experience, Postini gushes spam.  I can't say I'm very surprised
if the rest of Google finally noticed.  On my system, anything from
Postini goes into a special trap with specific filters that discard or
report nearly everything and pick out only a trickle of non-spam I've
noticed before.

Also, it is my understanding that they're winding down the general
purposes anti-spam stuff and turning it into a specialist provider for
HIPAA compliance and the like.

R's,
John

PS: My opinion of Postini was not helped by a colloquy a few years ago
with a recent ex-employee who found it bizarre and offensive that I
should expect Postini to take any responsibility at all for the mail
their customers pay them to send.
___
dmarc-discuss mailing list
dmarc-discuss@dmarc.org
http://www.dmarc.org/mailman/listinfo/dmarc-discuss

NOTE: Participating in this list means you agree to the DMARC Note Well terms 
(http://www.dmarc.org/note_well.html)

Re: [dmarc-discuss] gaah, never mind, DMARC rejections on domain with no DMARC record

[John Levine via dmarc-discuss]

I went back and found the original message, which contains this gem of a header:

  From: x...@netscape.net x...@aol.com

My scripts that check for DMARC-sensitive addresses got confused.  Never mind.

R's,
John
___
dmarc-discuss mailing list
dmarc-discuss@dmarc.org
http://www.dmarc.org/mailman/listinfo/dmarc-discuss

NOTE: Participating in this list means you agree to the DMARC Note Well terms 
(http://www.dmarc.org/note_well.html)

Re: [dmarc-discuss] On Inbound DMARC Support

[John Levine via dmarc-discuss]

 Nothing personal, but like 99.9% of the people in the world, I care
 nothing about your brand.

Which has no bearing on whether or not inbound DMARC filtering should be
considered for corporate infrastructure.

The point of DMARC is for mailbox operators to defend their own users.
If their users are suffering from the kind of stuff that DMARC deters,
they should use it, unrelated to what any outsiders want.  I discard
unsigned paypal.com mail because it keeps phish out of my users'
mailboxes, not because it makes Paypal happy.

 Like 99.9% of the people in the
world, you and I would never see the use of DMARC in these B2B cases.
But if it can help put any dent whatsoever in the endless stream of
corporate data breaches, for example, I think it's a net benefit for
consumers.

How can DMARC prevent breaches?  At most we've seen it defend
imperfectly against the consequences a very specific and unusual kind
of breach in which they stole address books of individual mail users.
For the typical breach of financial information, it's irrelevant.

R's,
John
___
dmarc-discuss mailing list
dmarc-discuss@dmarc.org
http://www.dmarc.org/mailman/listinfo/dmarc-discuss

NOTE: Participating in this list means you agree to the DMARC Note Well terms 
(http://www.dmarc.org/note_well.html)

Re: [dmarc-discuss] On Inbound DMARC Support

[John Levine via dmarc-discuss]

As a community promoting DMARC, we have an obligation to champion deployment 
at both ends - inbound as well as
outbound.  A first step is to let our vendors know DMARC support is 
requirement.

Um, perhaps they've heard about AOL and Yahoo and have reasonable
concerns about losing real mail.

DMARC does some things very well.  As we've seen, it does other things
considerably less well.  Glossing over the issues doesn't help
anyone's credibility.

 It is also a matter of respect.  If I want XYZ Corp to respect the
 controls around my brand, I need to respect the controls around
 theirs.

Nothing personal, but like 99.9% of the people in the world, I care
nothing about your brand.

R's,
John
___
dmarc-discuss mailing list
dmarc-discuss@dmarc.org
http://www.dmarc.org/mailman/listinfo/dmarc-discuss

NOTE: Participating in this list means you agree to the DMARC Note Well terms 
(http://www.dmarc.org/note_well.html)

Re: [dmarc-discuss] a detour into S/MIME, was MLM and Header-From rewriting

[John Levine via dmarc-discuss]

If your MUA shows you that this message is signed with a trusted
certificate, you're sorted. If you're in the minority (or so I believe)
for whom that isn't displayed, then boo; you're one of the few for whom
S/MIME signatures as a matter of course would achieve nothing.

Gmail: shows the signature as an attachment it can't decode

Yahoo: ignores the signature completely

Hotmail: ignores the signature completely

AOL: shows the signature as an attachment it can't decode, but does say it 
doesn't contain a virus

That's a pretty large minority.

R's,
John
___
dmarc-discuss mailing list
dmarc-discuss@dmarc.org
http://www.dmarc.org/mailman/listinfo/dmarc-discuss

NOTE: Participating in this list means you agree to the DMARC Note Well terms 
(http://www.dmarc.org/note_well.html)

Re: [dmarc-discuss] MLM and Header-From rewritting - the SMTPopen-relay analogy

[John Levine via dmarc-discuss]

On your most recent message my Mac client says �Unable to verify message 
signature�. Clicking on
�Show details� it says that the certificate is not valid, email address 
mismatch.

Alpine said it was signed, with a note at the bottom about the signing
address. Thunderbird said it had no signature.

I think we can say this is a corner case that MUAs don't address consistently.

___
dmarc-discuss mailing list
dmarc-discuss@dmarc.org
http://www.dmarc.org/mailman/listinfo/dmarc-discuss

NOTE: Participating in this list means you agree to the DMARC Note Well terms 
(http://www.dmarc.org/note_well.html)

Re: [dmarc-discuss] the obvious lookalike attack

[John Levine via dmarc-discuss]

A claim that attackers will use work-arounds creates a desire for
measuring use of work-arounds...

Here's an anecdote: I've been getting a fair amount of spam from what
are obviously stolen AOL address books, since I recognize the sender
and the other recipients.  Now I'm getting the same spam, but the
From: line has her name as the comment, same as always, but some
random non-AOL address.

I suppose that suggests that DMARC may have been somewhat effective at
stopping the phish using the exact address, so they're doing what lists
do, munge the address to hide it from DMARC.

R's,
John
___
dmarc-discuss mailing list
dmarc-discuss@dmarc.org
http://www.dmarc.org/mailman/listinfo/dmarc-discuss

NOTE: Participating in this list means you agree to the DMARC Note Well terms 
(http://www.dmarc.org/note_well.html)

Re: [dmarc-discuss] MLM and Header-From rewritting - the SMTP open-relay analogy

[John Levine via dmarc-discuss]

I cannot stop thinking that the push-back against MLMs rewriting the 
Header-From is akin to the push-back of about 28 years
ago from some people against the move to consider SMTP open-relays harmful.

This is about the fourth time around for this topic.  Any chance we
could just skip the preliminaries and refer to the archives for all of
the arguments?

R's,
John
___
dmarc-discuss mailing list
dmarc-discuss@dmarc.org
http://www.dmarc.org/mailman/listinfo/dmarc-discuss

NOTE: Participating in this list means you agree to the DMARC Note Well terms 
(http://www.dmarc.org/note_well.html)

Re: [dmarc-discuss] DMARC thwarted already?

[John Levine via dmarc-discuss]

Doesn’t this come back to the whitelist idea? For the green bar SSL certs 
(Extended
Validation), the certs have a bunch of information encoded in it, and the 
browsers have a
list of CA’s that they trust. AFAIK, the only way to do that for email is 
through DKIM but
you wouldn’t highlight all DKIM-signed email, only DKIM-signed email that you 
trust which
is compared against a whitelist.

Yes, definitely.  See RFC 5518 for one approach.

R's,
John
___
dmarc-discuss mailing list
dmarc-discuss@dmarc.org
http://www.dmarc.org/mailman/listinfo/dmarc-discuss

NOTE: Participating in this list means you agree to the DMARC Note Well terms 
(http://www.dmarc.org/note_well.html)