Re: [dmarc-discuss] DMARC forensic reporting options

[Franck Martin via dmarc-discuss]

John,

Are you ready to send failure reports for emails received by you?

Show the way, write about it, this may help others to do the same.

Thanks


On Fri, Dec 23, 2016 at 8:10 AM, John Comfort via dmarc-discuss <
dmarc-discuss@dmarc.org> wrote:

> Maybe it is time to rethink this, or open a more official dialogue.  I
> understand folks don't want to send reports.  I understand the privacy
> issue.  However, without these reports, or at least *some* information sent
> regarding the unaligned emails, we are at an impasse to migrating to a
> 'reject'.  For certain environments (e.g. financial), we cannot reject
> *any* legitimate emails and therefore require verification of all emails
> that are rejected.
>
> I would be perfectly fine with limiting the information if people are
> really that paranoid about header information.  For example:  date,
> receiving server information, originating smtp server sender, and subject
> line.  This would be a good start at least.
>
> Let's make DMARC powerful and efficient instead of a "cool idea".
>
> John
>
>
> On Wed, Dec 14, 2016 at 6:02 PM, John Levine  wrote:
>
>> >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)
>
___
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 quiet?

[Franck Martin via dmarc-discuss]

On Wed, Oct 26, 2016 at 8:47 AM, Payne, John  wrote:

>
>
> On Oct 26, 2016, at 11:36 AM, Franck Martin  wrote:
>
>
>
> 4) GApps DKIM signs all the emails with .gappssmtp.com
> 
> until said customer DKIM signs with its own domain (because they want all
> emails to be authenticated).
>
>
> Yeah, but why are they showing up in _my_ DMARC reports?
>
>
DMARC reports will contain all the valid and invalid DKIM signatures it
found in the email...
___
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 quiet?

[Franck Martin via dmarc-discuss]

Couple of points...

1) https://github.com/linkedin/dmarc-msys/blob/master/dmarc.lua#L804
This is how we detect if the email is likely to be from a mailing list. I
parse the logs from time to time, and put exceptions in our local policy.

2) very few lists discard DMARC protected emails on reception. So as long
you don't post too often, you are not triggering the unsubscribe due to
bounce function in mailman...

3) we tell our employees to use personnal email addresses for mailing
lists... It makes sure they are not speaking on our behalf ;)

4) GApps DKIM signs all the emails with .gappssmtp.com
until said customer DKIM signs with its own domain (because they want all
emails to be authenticated).



On Tue, Oct 25, 2016 at 1:14 PM, Payne, John via dmarc-discuss <
dmarc-discuss@dmarc.org> wrote:

>
> > On Sep 27, 2016, at 12:23 PM, Terry Zink via dmarc-discuss <
> dmarc-discuss@dmarc.org> wrote:
> >
> >> Somewhat related (to my earlier post) - are there any _enterprises_ on
> this list that have
> >> experience or are currently attempting to either go p=reject or enforce
> DMARC policies inbound?
> >
> > I just wrote one for Microsoft: https://blogs.msdn.microsoft.
> com/tzink/2016/09/27/how-we-moved-microsoft-com-to-a-
> pquarantine-dmarc-record/
>
> This is the blog post I wanted to write :)  I’m just behind on getting to
> p=quarantine.
>
> There are 2 things slowing me down:
>
> 1. As I just replied to Franck - enforcing inbound (which is my primary
> goal) - I need to handle mailing lists (and I don’t want to wait for ARC
> adoption).   So I have to figure out all the mailing lists my users are
> posting to so I can whitelist those IPs coming back unless anyone wants to
> share a list? :)
>
> 2. Google seems to report itself as a DMARC failing sender for unrelated
> domains to me.  This really started in earnest in March, but I’m getting
> 40k-60k what seem like unrelated reports a day, for example:
>
>
> Domain  MAIL FROM   DKIM domain SPF AuthDKIM Auth
>  Total
> akamai.com oppa.com.br oppa-com-br.20150623.gappssmtp.com Pass  Pass
> 237
>
> So that’s killing my confidence on publishing p=quarantine (I can fake one
> inbound).  Are others seeing this, or am I a special snowflake?
>
>
>
> Thanks
> 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)
>
___
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

[Franck Martin via dmarc-discuss]

I'm not sure what is the issue here? Mailing lists break DKIM by design. We
could go to the old style of mailing lists, which did not break DKIM, but
did not have, for instance, these nice footers to tell people how to
unsubscribe...

For the deployment of DNSSEC this is the wrong list, and let's face it,
DNSSEC has a difficult time to be adopted because:
https://ianix.com/pub/dnssec-outages.html

On Tue, Oct 4, 2016 at 7:50 AM, Benny Pedersen via dmarc-discuss <
dmarc-discuss@dmarc.org> wrote:

> Authentication-Results: linode.junc.eu; dmarc=pass header.from=dmarc.org
> Authentication-Results: linode.junc.eu;
> dkim=pass (1024-bit key; unprotected) header.d=dmarc.org
> header.i=@dmarc.org header.b=g7uNA2zS;
> dkim=fail reason="signature verification failed" (1024-bit key;
> secure) header.d=junc.eu header.i=@junc.eu header.b=rpMrxjyH;
> dkim-atps=neutral
>
> thanks all, is dmarc really so hard to not break ?
>
> when will dmarc.org have dnssec ?
>
> wake up admins
>
> would it be possible to skip last signer if multisigned ?, in the long
> term i would not accept such mails anymore, and i am also unimpressed of
> that dmarc can pass with no dnssec, badly designed
>
> or is it possibel to blacklist signer in dkim/dmarc ?
> ___
> 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] dmarc fail for linkedin

[Franck Martin via dmarc-discuss]

As Elizabeth said.

I suspect your implementation of openDMARC cannot see the SPF result in the
email.

You may want to read https://sourceforge.net/p/opendmarc/tickets/100/ they
suggest a few fixes...

Notably, do you have a recent public suffix list in your openDMARC config?

On Mon, Oct 3, 2016 at 12:20 PM, Elizabeth Zwicky via dmarc-discuss <
dmarc-discuss@dmarc.org> wrote:

> Those headers cannot all be true. If the SPF pass is right, then the DMARC
> fail is wrong. Look at fixing the DMARC calculation, not your calculations.
>
> Elizabeth
>
> On Monday, October 3, 2016, 4:59:53 AM PDT, DurgaPrasad - DatasoftComnet
> via dmarc-discuss  wrote:
>
> Actually I’m parsing the headers and based on the dmarc=fail and further
> checking whether it’s from a mailing list - assigning a score in
> spamassassin. If I need to use the fail in conjunction with the spf=pass -
> then that premise is shot right?
>
>
>
> Regards
>
> DP
>
>
>
> *From:* Franck Martin [mailto:fmar...@linkedin.com]
> *Sent:* 03 October 2016 23:56
> *To:* Roland Turner; DurgaPrasad - DatasoftComnet
> *Cc:* DMARC Discussion List
> *Subject:* Re: [dmarc-discuss] dmarc fail for linkedin
>
>
>
> Happy to help, but as Roland said the problem seems to be on the receiver
> side. SPF is pass and aligned, that alone should do a DMARC pass.
>
>
>
> On Sun, Oct 2, 2016 at 9:03 PM, Roland Turner via dmarc-discuss <
> dmarc-discuss@dmarc.org> wrote:
>
> This looks like a receiver-side bug. An SPF pass for bounces.linkedin.com
> implies a DMARC pass for linkedin.com so long as the linked.com policy
> specifies or defaults to relaxed alignment (it does).
>
>
>
> - Roland
>
>
>
>
>
> *Roland Turner*
> Labs Director
> *Mobile:* +65 9670 0022
> 3 Phillip Street, #13-03 Royal Group Building, Singapore 048693
> --
>
> 
>
> 
>
> 
>
> 
>
> *www.trustsphere.com* 
>
>   
>
>   
>
>   
> --
> 
>
>
>
>
> *From: dmarc-discuss  on behalf of
> DurgaPrasad - DatasoftComnet via dmarc-discuss
> Sent: Sunday, 2 October 2016 23:16To:
> 'dmarc-discuss'Subject: [dmarc-discuss] dmarc fail for linkedin
> *
>
>   
>
> Hello all, 
>
> Why is dmac failing for linkedin? 
>
> following sanitised output captured from mailwatch. I thought Linkedin is
> active participant of DMARC. 
>
> Sometimes it fails for gmail also.
> 
>
>   
>
>   
>
> Received from: 
>
> 108.174.6.157 
>
> Received Via: 
>
> *IP Address *
>
> *Hostname *
>
> *Country *
>
> *RBL *
>
> *Spam *
>
> *Virus *
>
> *All *
>
> 108.174.6.157 
>
> *mailb-de.linkedin.com* 
>
> United States 
>
>   
>
>   
>
>   
>
>   
>
>   
>
> X-Greylist: delayed 62 seconds by postgrey-1.34 at *sync.recvdomain.com*;
> Sun, 02 Oct 2016 20:10:32 IST
> DMARC-Filter: OpenDMARC Filter v1.3.1 *sync.recvdomain.com* 3561F1A4C04
> Authentication-Results: *sync.recvdomain.com*; dmarc=fail header.from=
> *linkedin.com*
> Authentication-Results: *sync.recvdomain.com*; spf=pass smtp.mailfrom=
> *s-2gvpcup5oqbkzh2ybkjw5b561o5y1w1xie7y74qzpfik7kyi2yfqr...@bounce.linkedin.com*
> Received: from *mailb-de.linkedin.com* (*mailb-de.linkedin.com*
> [108.174.6.157])
>  by *sync.recvdomain.com* (Postfix) with ESMTP id 3561F1A4C04
>  for <*a...@recvdomain.com*>; Sun, 2 Oct 2016 20:10:31 +0530 (IST)
> DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=*linkedin.com*;
>  s=proddkim1024; t=1475419164;
>  bh=0BGcec8gfa2UUrhh3rWJw+dpo9wKPor0X6Nmr4swfos=;
>  h=From:Subject:MIME-Version:Content-Type:To:Date:X-LinkedIn-Class:
>   

Re: [dmarc-discuss] dmarc fail for linkedin

[Franck Martin via dmarc-discuss]

Happy to help, but as Roland said the problem seems to be on the receiver
side. SPF is pass and aligned, that alone should do a DMARC pass.

On Sun, Oct 2, 2016 at 9:03 PM, Roland Turner via dmarc-discuss <
dmarc-discuss@dmarc.org> wrote:

> This looks like a receiver-side bug. An SPF pass for bounces.linkedin.com
> implies a DMARC pass for linkedin.com so long as the linked.com policy
> specifies or defaults to relaxed alignment (it does).
>
>
> - Roland
>
>
>
> *Roland Turner*
> Labs Director
> *Mobile:* +65 9670 0022
> 3 Phillip Street, #13-03 Royal Group Building, Singapore 048693
> --
>  
> 
>  *www.trustsphere.com*
> 
>
>
>
> --
> *From:* dmarc-discuss  on behalf of
> DurgaPrasad - DatasoftComnet via dmarc-discuss 
> *Sent:* Sunday, 2 October 2016 23:16
> *To:* 'dmarc-discuss'
> *Subject:* [dmarc-discuss] dmarc fail for linkedin
>
>
> Hello all,
>
> Why is dmac failing for linkedin?
>
> following sanitised output captured from mailwatch. I thought Linkedin is
> active participant of DMARC.
>
> Sometimes it fails for gmail also.
>
>
>
>
>
> Received from:
>
> 108.174.6.157
>
> Received Via:
>
> *IP Address*
>
> *Hostname*
>
> *Country*
>
> *RBL*
>
> *Spam*
>
> *Virus*
>
> *All*
>
> 108.174.6.157
>
> mailb-de.linkedin.com
>
> United States
>
>
>
>
>
>
>
>
>
>
>
> X-Greylist: delayed 62 seconds by postgrey-1.34 at sync.recvdomain.com;
> Sun, 02 Oct 2016 20:10:32 IST
> DMARC-Filter: OpenDMARC Filter v1.3.1 sync.recvdomain.com 3561F1A4C04
> Authentication-Results: sync.recvdomain.com; dmarc=fail header.from=
> linkedin.com
> Authentication-Results: sync.recvdomain.com; spf=pass smtp.mailfrom=s-
> 2gvpcup5oqbkzh2ybkjw5b561o5y1w1xie7y74qzpfik7kyi2yfqrk2t@
> bounce.linkedin.com
> Received: from mailb-de.linkedin.com (mailb-de.linkedin.com
> [108.174.6.157])
>  by sync.recvdomain.com (Postfix) with ESMTP id 3561F1A4C04
>  for ; Sun, 2 Oct 2016 20:10:31 +0530 (IST)
> DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linkedin.com;
>  s=proddkim1024; t=1475419164;
>  bh=0BGcec8gfa2UUrhh3rWJw+dpo9wKPor0X6Nmr4swfos=;
>  h=From:Subject:MIME-Version:Content-Type:To:Date:X-LinkedIn-Class:
>   X-LinkedIn-Template:X-LinkedIn-fbl;
>  b=o/PNleMe51U0pZDfW/LAVdNKiv2C4ovHt5yvMj1yrIhPfRBMKGtcGYSk67Vfl7CKx
>   sHutanfc5qs/eUEKnE3kMH5d2ErQ6PrVf89XBoQJtdLTOkMAAi7xEMFeE3FG0kY7Dw
>   otmGefhsAJezAVhhv0enUvM5Lho7jEcJ3xFcksls=
> From: John Kennedy 
> Message-ID: <401079548.70154.1475419164807.JavaMail.app@
> lva1-app2439.prod.linkedin.com>
> Subject: Abc, please add me to your LinkedIn network
> MIME-Version: 1.0
> Content-Type: multipart/alternative;
>  boundary="=_Part_70152_1116365500.1475419164803"
> To: Abc Ganta 
> Date: Sun, 2 Oct 2016 14:39:24 + (UTC)
> X-LinkedIn-Class: INVITE-MBR
> X-LinkedIn-Template: email_m2m_invite_single_01
> X-LinkedIn-fbl: m2-at007hio5vmhecl55aegbrldj55dod
> 8ekz33kb3ea8tqs5z1y4pek73m8v82dh9r3w53jdybhoksmyfs6cs0g1gofydssh0dlrpf0p
> X-LinkedIn-Id: 2j1zjf-itsqh361-p8
> List-Unsubscribe:  unsubscribe/AQFHINMWGdBNHwAAAVeF1dCG2mwGmj1UB3Tv6UiVZOiuykyYxJ2Gg2W1-_
> q2uw2WyTZC3eV8QBIcs-Vn9Xk8qE0eQfg/2j1zjf-itsqh361-p8/m2-
> at007hio5vmhecl55aegbrldj55dod8ekz33kb3ea8tqs5z1y4pek73m8v82
> dh9r3w53jdybhoksmyfs6cs0g1gofydssh0dlrpf0p>
> Require-Recipient-Valid-Since: a...@recvdomain.com; Wed, 14 Aug 2013
> 00:00:00 +
>
> From:
>
> s-2gvpcup5oqbkzh2ybkjw5b561o5y1w1xie7y74qzpfik7kyi2yfqrk2t@
> bounce.linkedin.com
>
>
>
>
>
> Regards
>
> Durga Prasad
>
>
>
>
> --
> [image: Avast logo]
> 
>
> This email has been checked for viruses by Avast antivirus software.
> www.avast.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] DMARC and null path

[Franck Martin via dmarc-discuss]

The definition of RFC7489.MAILFROM is not the same as RFC5321.Mailfrom

RFC7489.MAILFROM is RFC5321.MailFrom if it is not empty, otherwise it is
postmaster@

On Mon, May 9, 2016 at 12:50 PM, Maarten Oelering <maar...@postmastery.net>
wrote:

> Hi Franck,
>
> You explained this before, but also then I didn’t quite understand.
>
> First you say there is the SPF check on HELO and on MAILFROM. That I know
> and understand.
> Then you say DMARC only uses the RFC5321.Mailfrom, but which includes
> falls back on RFC5321.Helo.
>
> But isn’t that the same in practice? The HELO domain is the HELO domain.
> Or is the difference that alignment is required when postmaster@
> is used in DMARC context?
>
> Thanks,
>
> Maarten
>
> On 9 mei 2016, at 19:27, Franck Martin via dmarc-discuss <
> dmarc-discuss@dmarc.org> wrote:
>
> SPF provides 2 results. People get confused because they often think there
> is only one.
>
> The first result is based on the RFC7489.HELO and the second result is
> based on the RFC7489.MAILFROM.
>
> The first result could allow you to close a connection at the RFC5321.Helo
> stage, while the second result would allow you to close the connection
> after the RFC5321.Mailfrom. In practice both results are integrated in
> higher reputation layers...
>
> DMARC uses only the second result (and identifiers).
>
> As a side note and as Terry points out, Office 365, only uses the second
> results for SPF. Many implementations of SPF use only the second result.
>
> RFC7489.MAILFROM is defined as RFC5321.MailFrom unless it is empty, in
> that case it is postmaster@
>
> Hope this helps.
>
> On Mon, May 9, 2016 at 8:17 AM, Terry Zink via dmarc-discuss <
> dmarc-discuss@dmarc.org> wrote:
>
>> This is a good point, I'm not sure about how others do it, but in Office
>> 365 we compare the 5322.From domain against the domain that was used to
>> authenticate SPF. That's the 5321.MailFrom unless it is <>, in which case
>> we use the HELO/EHLO domain. That would allow a DMARC pass in the absence
>> of a DKIM signature.
>>
>> -- Terry
>>
>> -Original Message-
>> From: dmarc-discuss [mailto:dmarc-discuss-boun...@dmarc.org] On Behalf
>> Of Sistemisti Posta via dmarc-discuss
>> Sent: Monday, May 9, 2016 3:38 AM
>> To: dmarc-discuss@dmarc.org
>> Subject: [dmarc-discuss] DMARC and null path
>>
>> Hello DMARC users,
>>
>>because I'm new in DMARC world I'm trying to understand some details
>> before to start with policy implementation.
>>
>> A detail I would understand is related to mails with null path, or null
>> sender address, typically sent by Delivery Status Notifications.
>>
>> It seems that the only way to pass DMARC with null path is to DKIM sign
>> the mails. Is it true?
>>
>> I ask this because RFC7489 says that exists a condition when DMARC
>> considers the null path:
>>
>> "Note that the RFC5321.HELO identity is not typically used in the
>> context of DMARC (except when required to "fake" an otherwise null
>> reverse-path)"
>>
>> And:
>>
>> "DMARC uses the result of SPF authentication of the MAIL FROM identity.
>> Section 2.4 of [SPF] describes MAIL FROM processing for cases in which
>> the MAIL command has a null path."
>>
>> RFC4408 says accordingly:
>>
>> 'When the reverse-path is null, this document defines the "MAIL FROM"
>> identity to be the mailbox composed of the localpart "postmaster" and
>> the "HELO" identity (which may or may not have been checked separately
>> before).'
>>
>> So if a mail with null path and HELO domain equal to RFC5322.From passes
>> the SPF check, why should DMARC fail?
>>
>> See at this live example:
>>
>> libero.it descriptive text "v=spf1 ip4:212.48.25.128/25
>> ip4:212.48.14.160/27 include:srs.bis.na.blackberry.com
>> include:srs.bis.eu.blackberry.com include:srs.bis.ap.blackberry.com
>> include:mail.zendesk.com -all"
>> _dmarc.libero.it descriptive text "v=DMARC1\; p=quarantine\; ...
>>
>> If 212.48.14.166 sends a mail with null path,
>> RFC5322.From=@libero.it and *helo=libero.it*, then SPF thinks to
>> have a 'MAIL FROM' like "postmas...@libero.it", passing this result to
>> DMARC for alignment with RFC5322.From. (If it passes the helo domain is
>> the same)
>>
>> The result I see:
>> ~~~
>> 2016-05-09T09:47:06.481095+02:00 postfix/smtpd[14063]: 3r3Dx63PshzFpVy:
>> client=smtp-32-i6.italiaonline.it[212.48.14.166]
>> 

Re: [dmarc-discuss] Failure reports from Microsoft servers due to SPF and DKIM both failing for forwarded/resent messages

[Franck Martin via dmarc-discuss]

MS-Exchange tends to normalize the email (like fix html) before storing it
(in TNEF format) or forwarding it. It is known, and is being addresses.
Several fixes have been in place in office365 (less so for on-premises
systems), but your mileage may vary...

A search through the list archives may help you.

On Tue, Apr 19, 2016 at 4:10 AM, Geir Waade via dmarc-discuss <
dmarc-discuss@dmarc.org> wrote:

> Hello,
>
>
>
> We have been ramping up DMARC usage over the last year or so, and recently
> enabled the failure reporting option to allow recipient servers to notify
> us when a message is quarantined or rejected due to a failing policy. We
> have SPF and DKIM in place for our domains and have set the failure policy
> to fo=0, which requires both SPF and DKIM to fail for the DMARC check to
> fail.
>
>
>
> What we've noticed is a potential problem with certain conditions of
> message forwarding, resulting in a bit of failure report flooding. Whenever
> we send a message to someone with a Hotmail/MSN/Outlook.com address, who
> has configured their account to forward email to another address on
> Microsoft's services (Office365 / Exchange hybrid?), we get DMARC failure
> reports from st...@hotmail.com. The headers in the report's attached
> emails show that delivery from our servers to the hotmail server for the
> original address succeeds, with both SPF and DKIM checks passing. However,
> there's an internal delivery exchange of the message between outlook.com
> / hotmail.com / onmicrosoft servers for the new recipient's address, and
> the recipient's server performs a new authentication check on the forwarded
> message. This fails the SPF check, which is to be expected, but should not
> be enough to fail the message per our DMARC policy of 'fo=0'.  However, for
> some reason it also fails the DKIM check at this point – possibly due to a
> modified subject or an added anti-spam scan disclaimer? The final
> recipient's server politely adheres to our DMARC policy and
> rejects/quarantines the message, and we get a failure report as a result.
>
>
>
> Is there anything we can do as a sender to prevent this from happening,
> beyond relaxing the policy to maybe quarantine less than 100% of failed
> messages? It seems odd that we are getting an abundance of these from
> Microsoft, but almost nothing from other services. Has Microsoft
> implemented some superfluous auth checks in their internal delivery line
> that fails due to them breaking the DKIM signature on a previous step, or
> is possibly this due to Office365 customer setup?
>
>
>
> I have several examples of emails with headers showing the odd forwarding
> path these messages take, if you'd be interested in taking a look. Any
> suggestions you can give us would be most welcome.
>
>
>
> Best regards,
>
> Geir W
>
> ___
> 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] is that *really* valid

[Franck Martin via dmarc-discuss]

Even in this case Lastname is not a valid mailbox as it does not have a
valid email address, even when you take into account the EAI update it
should have been written as Lastname;

Strictly speaking the ABNI allows display name with no double quotes as
long you don't use any special characters like comma, @, and I believe
space... but I often get lost in ABNI.

On Wed, Apr 6, 2016 at 9:41 AM, A. Schulze via dmarc-discuss <
dmarc-discuss@dmarc.org> wrote:

>
> Franck Martin via dmarc-discuss:
>
> Vladimir,
>>
>> We are not discussing here the fact you can put 2 mailboxes in a From: but
>> that the display part must be between double quotes.
>>
>
> Franck,
>
> that's the point.
>
> The message in question look like an auto-response from Yahoo!.
> I *assume* it should only have one sender but due to $something there
> where quotes missing.
> I'll forward the message headers to Yahoo! off-list.
>
> Anyway, as this message was valid per RFC 5322 but invalid per RFC 7489
> OpenDMARC correctly rejected that message. No bug so far.
>
> Thanks!
>
> Andreas
>
> ___
> 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] is that *really* valid

[Franck Martin via dmarc-discuss]

Vladimir,

We are not discussing here the fact you can put 2 mailboxes in a From: but
that the display part must be between double quotes.

A mailbox is an optional display part within double quotes followed by an
email address within <>. Mailboxes are separated by comas ,.

On Wed, Apr 6, 2016 at 8:55 AM, Vladimir Dubrovin via dmarc-discuss <
dmarc-discuss@dmarc.org> wrote:

>
> This From contains 2 mailboxes (Lastname and u...@yahoo.com). This is
> valid RFC 5322 syntax
>
>from=   "From:" mailbox-list CRLF
> ...
>  mailbox-list=   (mailbox *("," mailbox)) / obs-mbox-list
>
> but it's invalid for DMARC RFC 7489 and it's not covered by DMARC
> specification:
>
>The absence of a single, properly formed RFC5322 
> .From field renders
>the message invalid.  Handling of such a message is outside of the
>scope of this specification.
>
> Processing of message like this is implementation specific, any
> implementation does not violate RFC 7489.
>
> A. Schulze via dmarc-discuss пишет:
>
>
> Hello,
>
> I noticed a message with this RFC5322.From:
>
>   From: Lastname, Firstname  
>
> the message was authenticated by SPF and DKIM but opendmarc rejected
> finally.
> Is this From really valid? I would quote the displayname.
>
> If it's valid, I hit a bug in OpenDMARC.
> If it's invalid, maybe Elizabeth will be interested ...
>
> Andreas
>
> ___
> 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)
>
>
>
> --
> Vladimir Dubrovin
> [image: @Mail.Ru]
>
> ___
> 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] is that *really* valid

[Franck Martin via dmarc-discuss]

It happens a lot..

The obsoleted format allowed it, not the recent one. I think we should
ignore the obsolete format now...

The problem is:
From: j...@example.com 

Which certain quite old versions of .net do.


On Wed, Apr 6, 2016 at 3:26 AM, A. Schulze via dmarc-discuss <
dmarc-discuss@dmarc.org> wrote:

>
> Hello,
>
> I noticed a message with this RFC5322.From:
>
>   From: Lastname, Firstname 
>
> the message was authenticated by SPF and DKIM but opendmarc rejected
> finally.
> Is this From really valid? I would quote the displayname.
>
> If it's valid, I hit a bug in OpenDMARC.
> If it's invalid, maybe Elizabeth will be interested ...
>
> Andreas
>
> ___
> 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] Multiple SPF results in report

[Franck Martin via dmarc-discuss]

The question, is what is the RFC5321.mailfrom is empty? The
RFC7208.MAILFROM is never empty.

https://tools.ietf.org/html/rfc7208#section-2.4

SPF verifiers MUST check the "MAIL FROM" identity if a "HELO" check
   either has not been performed or has not reached a definitive policy
   result by applying the check_host() function to the "MAIL FROM"
   identity as the .

   [RFC5321] allows the reverse-path to be null (see Section 4.5.5 in
   [RFC5321] <https://tools.ietf.org/html/rfc5321#section-4.5.5>).  In
this case, there is no explicit sender mailbox, and
   such a message can be assumed to be a notification message from the
   mail system itself.  When the reverse-path is null, this document
   defines the "MAIL FROM" identity to be the mailbox composed of the
   local-part "postmaster" and the "HELO" identity (which might or might
   not have been checked separately before).



On Mon, Apr 4, 2016 at 8:59 AM, Lugo, Dave via dmarc-discuss <
dmarc-discuss@dmarc.org> wrote:

> Franck,
>
> What if the RFC7208.MAILFROM is empty?  I recall some questions from
> colleagues re dmarc reporting and the spf scope (help or mailfrom).
>
> Thanks,
>
> Dave
>
> --
> Dave Lugo
> Engineer, Comcast Anti-Abuse Technologies
> Desk: 215-286-5451
>
>
> From: dmarc-discuss <dmarc-discuss-boun...@dmarc.org> on behalf of Franck
> Martin via dmarc-discuss <dmarc-discuss@dmarc.org>
> Reply-To: Franck Martin <fmar...@linkedin.com>
> Date: Monday, April 4, 2016 at 11:51 AM
> To: Maarten Oelering <maar...@postmastery.net>
> Cc: "n...@graafhenk.nl" <n...@graafhenk.nl>, DMARC Discussion List <
> dmarc-discuss@dmarc.org>
> Subject: Re: [dmarc-discuss] Multiple SPF results in report
>
> It is a bug.
>
> There can only be one SPF per record. Theoretically SPF returns 2 results,
> one for the RFC7208.HELO and another one for RFC7208.MAILFROM, but DMARC
> takes as input only RFC7208.MAILFROM, therefore only this results is needed
> in DMARC reports.
>
> RFC7208.MAILFROM is not RFC5321.MailFrom, there is a subtle but important
> difference here.
>
> On Mon, Apr 4, 2016 at 12:23 AM, Maarten Oelering via dmarc-discuss <
> dmarc-discuss@dmarc.org> wrote:
>
>> Do you mean that in the XML you see 6  elements in one
>>  element? Or do you mean you see 6 different  domains in
>> the your reports?
>>
>> Maarten Oelering
>> Postmastery
>>
>> On 4 apr. 2016, at 09:05, Nick via dmarc-discuss <dmarc-discuss@dmarc.org>
>> wrote:
>>
>> I received a DMARC report with multiple SPF results. I wonder how this is
>> possible as I only have one SPF record for my domain defined. In one report
>> I got 6 SPF results.
>>
>> The only thing I could think of is some automatic forwarding service
>> changing the return path header. Are there more usecases possible how this
>> can happen?
>>
>> Thanks
>> Nick
>> ___
>> 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)
>>
>
>
> ___
> 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] Multiple SPF results in report

[Franck Martin via dmarc-discuss]

It is a bug.

There can only be one SPF per record. Theoretically SPF returns 2 results,
one for the RFC7208.HELO and another one for RFC7208.MAILFROM, but DMARC
takes as input only RFC7208.MAILFROM, therefore only this results is needed
in DMARC reports.

RFC7208.MAILFROM is not RFC5321.MailFrom, there is a subtle but important
difference here.

On Mon, Apr 4, 2016 at 12:23 AM, Maarten Oelering via dmarc-discuss <
dmarc-discuss@dmarc.org> wrote:

> Do you mean that in the XML you see 6  elements in one 
> element? Or do you mean you see 6 different  domains in the your
> reports?
>
> Maarten Oelering
> Postmastery
>
> On 4 apr. 2016, at 09:05, Nick via dmarc-discuss 
> wrote:
>
> I received a DMARC report with multiple SPF results. I wonder how this is
> possible as I only have one SPF record for my domain defined. In one report
> I got 6 SPF results.
>
> The only thing I could think of is some automatic forwarding service
> changing the return path header. Are there more usecases possible how this
> can happen?
>
> Thanks
> Nick
> ___
> 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)
>
___
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] Reminder: Yahoo DMARC policy change on March 28th

[Franck Martin via dmarc-discuss]

you may want to post this on mailop too? Or I can post it for you.

On Tue, Mar 22, 2016 at 11:35 AM, Sumeet Solanki via dmarc-discuss <
dmarc-discuss@dmarc.org> wrote:

> [image: Purple]
>
> Dear members,
>
> This is a final reminder that on March 28th (Monday), Yahoo will switch to
> a p=reject DMARC policy for the below 62 international domains. Email sent
> from a mailbox hosted on these domains will be rejected if they fail
> DMARC.  Please make any changes needed to handle them the same way
> yahoo.com is handled. Thank you.
>
> y7mail.com
> yahoo.at
> yahoo.be
> yahoo.bg
> yahoo.cl
> yahoo.co.hu
> yahoo.co.id
> yahoo.co.il
> yahoo.co.kr
> yahoo.co.th
> yahoo.co.za
> yahoo.com.co
> yahoo.com.hr
> yahoo.com.my
> yahoo.com.pe
> yahoo.com.ph
> yahoo.com.sg
> yahoo.com.tr
> yahoo.com.tw
> yahoo.com.ua
> yahoo.com.ve
> yahoo.com.vn
> yahoo.cz
> yahoo.dk
> yahoo.ee
> yahoo.fi
> yahoo.hr
> yahoo.hu
> yahoo.ie
> yahoo.lt
> yahoo.lv
> yahoo.nl
> yahoo.no
> yahoo.pl
> yahoo.pt
> yahoo.rs
> yahoo.se
> yahoo.si
> yahoo.sk
> yahoogroups.co.kr
> yahoogroups.com.cn
> yahoogroups.com.sg
> yahoogroups.com.tw
> yahoogrupper.dk
> yahoogruppi.it
> yahooxtra.co.nz
> yahoo.ca
> yahoo.co.in
> yahoo.co.nz
> yahoo.co.uk
> yahoo.com.ar
> yahoo.com.au
> yahoo.com.br
> yahoo.com.hk
> yahoo.com.mx
> yahoo.de
> yahoo.es
> yahoo.fr
> yahoo.gr
> yahoo.in
> yahoo.it
> yahoo.ro
>
> Regards,
>
> Sumeet S. Solanki, Senior Product Manager
> Elizabeth Zwicky, Antispam Architect
>
> Yahoo Mail
> [image: Purple]
> Yahoo Mail Stationery
> 
>
> ___
> 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] introduction to the list-virtual server & mailman questions

[Franck Martin via dmarc-discuss]

On Mon, Feb 15, 2016 at 10:53 PM, Scott Kitterman via dmarc-discuss
 wrote:
> On Tuesday, February 16, 2016 06:17:27 AM Roland Turner via dmarc-discuss
> wrote:
>> Scott Kitterman wrote:

>>
>> 1: I *don't* believe that this would take the form of a whitelist. It's more
>> like the ability to recognise changes in baseline behaviour by forwarders
>> who may or may not be ARC signing. I suspect that John Levine's concerns
>> about whitelists have some strength.
>
> It would as that data is the barrier to entry I'm worried about.  I think it's
> actually two lists:
>
> 1.  Domains good enough you ought to trust to believe what they say in ARC.
> 2.  Domains bad enough you ought to reject their mail if they show up in ARC.
>
> I do wonder though if I have the data to toss the message why they didn't in
> the first place (and if they didn't why I should trust them).  So generically,
> yes, but I'm not certain what the characteristics of such a data source would
> be.
>

I looked at spamassassin and they don't do this work: take all the
domains in From, Reply-to, Sender, Dkim,... and evaluate them against
Domain Blocking lists and rejecting or scoring the email... they would
argue it is not a clear indicator of spam. Indeed, it has plenty false
positives but it obliges the domain owners to clean their domain or
practices... If I had the time to code some new spamassassin rules.

On the barrier to entry, I'm not sure an enterprise/organization can
run a mail system without some form of paid appliance/services to
filter out spam/phish/malware.

Yes I'm mindful that any clued admin should be able to run a mail
system. I don't think so far I have seen anyone making it impossible.
If you do the right things, your email can be sent and will be
accepted. The difficulty is how much spam you will be able to filter
for your incoming mail into your system. Paid services seems to
provide less risk.
___
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

[Franck Martin via dmarc-discuss]

The problem with the e-mail community, is few people drives all of us
away from mailing lists.

On Mon, Feb 15, 2016 at 3:47 PM, John R Levine  wrote:
>> As I said earlier spamhaus and surbl has the data. The question is not
>> which domains to trust, but which domains not to trust.
>
>
> No, really, they don't.  Take it from someone who actually writes MTA
> software, and probably knows more than most people about what's in the DBL.
>
>
>>> 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.
___
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

[Franck Martin via dmarc-discuss]

As I said earlier spamhaus and surbl has the data. The question is not
which domains to trust, but which domains not to trust.

On Mon, Feb 15, 2016 at 3:35 PM, John Levine  wrote:
>>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

[Franck Martin via dmarc-discuss]

Spamhaus and SURBL both publish a domain blocking list, this is enough to
use to block emails that went through bad domains (as per ARC custody chain)

Of course, this has to be built into the MTA, but it is all opensource, it
is not out of reach, just volunteers and work...

On Mon, Feb 15, 2016 at 3:00 PM, Scott Kitterman via dmarc-discuss <
dmarc-discuss@dmarc.org> wrote:

> The difference in this case is one, maintaining a Wordpress site, requires
> a
> lot of vigilance, but no information/data that's not publicly available.
> To
> the extent ARC is useful to mitigate the DMARC mailing list issue, it's
> only
> useful with additional data inputs that are not public and are not feasible
> for small providers to generate on their own.
>
> It's the difference between can, but often shouldn't and can't.
>
> I'll stop here though, the horse was probably dead a few mails ago.
>
> Scott K
>
> On Monday, February 15, 2016 02:11:57 PM Al Iverson via dmarc-discuss
> wrote:
> > Scott, I don't really see any difference in the class of problem. You
> could
> > choose to outsource email it to Google Apps or Microsoft Office 365 if
> you
> > don't want to figure this stuff out yourself. Many do, from SMB to
> > enterprise level, even though email is core to just about every company's
> > business. For some, that's very much the reason to job it out to a
> company
> > who focuses on email as an area of expertise.
> >
> > On the flip side, I disagree with regard to your take on running a blog.
> > Anybody can do it, but many people outsource that as well. I personally
> > host my blog with a third party service, because self-hosted Wordpress is
> > one of the most hacked into things out there and I want no part of that
> > noise, even though in theory I could handle it. I know I'm not the only
> > one, and just about anything in this paragraph could similarly apply to
> > email.
> >
> > Regards,
> > Al Iverson
> >
> >
> > --
> > Al Iverson - Minneapolis - (312) 275-0130
> > Simple DNS Tools since 2008: xnnd.com
> > www.spamresource.com & aliverson.com
> >
> > On Mon, Feb 15, 2016 at 1:35 PM, Franck Martin via dmarc-discuss <
> >
> > dmarc-discuss@dmarc.org> wrote:
> > > 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.
> > >
> > > If email is your core business, then complaining you have to do some
> work,
> > > will not give any sympathy.
> > >
> > > On Mon, Feb 15, 2016 at 11:17 AM, Scott Kitterman via dmarc-discuss <
> > >
> > > dmarc-discuss@dmarc.org> wrote:
> > >> That's a totally different class of problem.  Any competent sysadmin
> with
> > >> some
> > >> time can maintain a CMS based web site (e.g. Wordpress).  The fact
> that
> > >> so
> > >> many are not competently managed is a function of capability and
> > >> willingness
> > >> to do a little work, not a function of inadequate scale.
> > >>
> > >> Also, following that example, I choose to blog on wordpress.com,
> > >> specifically
> > >> so I don't have to worry about such things, but the blog isn't a core
> > >> business
> > >> function, so that's fine.  Email is more important, so I care more how
> > >> and
> > >> where it gets done.
> > >>
> > >> Scott K
> > >>
> > >> On Monday, February 15, 2016 10:56:57 AM Franck Martin via
> dmarc-discuss
> > >>
> > >> wrote:
> > >> > Yes it is a "you have to be this tall to ride with us". For
> instance,
> > >>
> > >> many
> > >>
> > >> > Wordpress sites are on URL blocking lists, because the managers
> cannot
> > >>
> > >> keep
> > >>
> > >> > with basic security updates. So if you want to host a website, you
> have
> > >>
> > >> to
> > >>
> > >> > be that tall to ride with us (or find a hosting company, that will
> give
> > >>
> > >> you
> > >>
> > >> > a child seat)
> > >> >
> > >> > The mail ecosystem is going this way too. The tools are opensource,
> > >> > available to all, but you need to deploy them and maintain them.
> > >> >
> > >> > The spat of serious data 

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

[Franck Martin 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.

If email is your core business, then complaining you have to do some work,
will not give any sympathy.

On Mon, Feb 15, 2016 at 11:17 AM, Scott Kitterman via dmarc-discuss <
dmarc-discuss@dmarc.org> wrote:

> That's a totally different class of problem.  Any competent sysadmin with
> some
> time can maintain a CMS based web site (e.g. Wordpress).  The fact that so
> many are not competently managed is a function of capability and
> willingness
> to do a little work, not a function of inadequate scale.
>
> Also, following that example, I choose to blog on wordpress.com,
> specifically
> so I don't have to worry about such things, but the blog isn't a core
> business
> function, so that's fine.  Email is more important, so I care more how and
> where it gets done.
>
> Scott K
>
> On Monday, February 15, 2016 10:56:57 AM Franck Martin via dmarc-discuss
> wrote:
> > Yes it is a "you have to be this tall to ride with us". For instance,
> many
> > Wordpress sites are on URL blocking lists, because the managers cannot
> keep
> > with basic security updates. So if you want to host a website, you have
> to
> > be that tall to ride with us (or find a hosting company, that will give
> you
> > a child seat)
> >
> > The mail ecosystem is going this way too. The tools are opensource,
> > available to all, but you need to deploy them and maintain them.
> >
> > The spat of serious data breaches because of email, is making all of us
> > very nervous that kids can create so much havoc so easily...
> >
> > On Sun, Feb 14, 2016 at 11:27 PM, Roland Turner via dmarc-discuss <
> >
> > dmarc-discuss@dmarc.org> wrote:
> > > Scott Kitterman wrote:
> > > > It would be nice if we didn't design standards that only worked at a
> > >
> > > certain
> > >
> > > > scale.  "You must be this tall to ride" worries me.
> > >
> > > There's nothing about ARC that is scale-specific, except for the
> obvious
> > > observation that there's a batteries-not-included problem, so the
> analysis
> > > work required to make good use of it as a receiver is likely to be
> > > infeasible for smaller receivers meaning that:
> > >
> > > - initially only larger receivers will do it, and
> > > - if it works then, over time, vendors/developers will embed
> slow-moving
> > > pieces in products and/or reputation data providers will add faster
> moving
> > > pieces to their services.
> > >
> > > This is just a diffusion process, not an exclusion of smaller players.
> > > Indeed, it would almost appear that you'd be happier if the big guys
> had
> > > excluded smaller players from this initiative...
> > >
> > > I'd also point out that we spent most of a decade (2003 - 2011)
> wandering
> > > in a highly-inclusive -all/o=-/discardable wilderness. It took the
> world's
> > > most-heavily-phished organisation working directly with one of the big
> > > guys
> > > in private to get any purchase on the problem, and their subsequent
> > > sharing
> > > of it (DMARC) to bring about progress more broadly. It would appear
> that
> > > ARC is on a similar path to improving the situation for largest
> unresolved
> > > piece of the problem (supporting forwarding). This does suggest a
> general
> > > difficulty in using a consensus-driven process to devise solutions,
> rather
> > > than merely refine/standardise/evolve them, however this does not seem
> > > like
> > > a reason for concern, it may simply indicate that we've gotten as far
> as
> > > we
> > > can get at present with such processes. The important test when
> deciding
> > > whether to cooperate would appear to be whether the particular solution
> > > unduly benefits the big guys compared to other viable solutions that
> are
> > > already known about. !
> > >
> > >  If there are none, then cooperating on ARC would appear to be a
> > >
> > > no-brainer.
> > >
> > > > Solving the mailing list 'problem' in a way that requires me to
> switch
> > > > to
> > > > gmail (or some other large scale provider) to get my list mail
> delivered
> > >
> > > is
> > >
> > > > worse than no solution at all for me.
> > >
> > > Obvi

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

[Franck Martin via dmarc-discuss]

Yes it is a "you have to be this tall to ride with us". For instance, many
Wordpress sites are on URL blocking lists, because the managers cannot keep
with basic security updates. So if you want to host a website, you have to
be that tall to ride with us (or find a hosting company, that will give you
a child seat)

The mail ecosystem is going this way too. The tools are opensource,
available to all, but you need to deploy them and maintain them.

The spat of serious data breaches because of email, is making all of us
very nervous that kids can create so much havoc so easily...

On Sun, Feb 14, 2016 at 11:27 PM, Roland Turner via dmarc-discuss <
dmarc-discuss@dmarc.org> wrote:

> Scott Kitterman wrote:
>
> > It would be nice if we didn't design standards that only worked at a
> certain
> > scale.  "You must be this tall to ride" worries me.
>
> There's nothing about ARC that is scale-specific, except for the obvious
> observation that there's a batteries-not-included problem, so the analysis
> work required to make good use of it as a receiver is likely to be
> infeasible for smaller receivers meaning that:
>
> - initially only larger receivers will do it, and
> - if it works then, over time, vendors/developers will embed slow-moving
> pieces in products and/or reputation data providers will add faster moving
> pieces to their services.
>
> This is just a diffusion process, not an exclusion of smaller players.
> Indeed, it would almost appear that you'd be happier if the big guys had
> excluded smaller players from this initiative...
>
> I'd also point out that we spent most of a decade (2003 - 2011) wandering
> in a highly-inclusive -all/o=-/discardable wilderness. It took the world's
> most-heavily-phished organisation working directly with one of the big guys
> in private to get any purchase on the problem, and their subsequent sharing
> of it (DMARC) to bring about progress more broadly. It would appear that
> ARC is on a similar path to improving the situation for largest unresolved
> piece of the problem (supporting forwarding). This does suggest a general
> difficulty in using a consensus-driven process to devise solutions, rather
> than merely refine/standardise/evolve them, however this does not seem like
> a reason for concern, it may simply indicate that we've gotten as far as we
> can get at present with such processes. The important test when deciding
> whether to cooperate would appear to be whether the particular solution
> unduly benefits the big guys compared to other viable solutions that are
> already known about. !
>  If there are none, then cooperating on ARC would appear to be a
> no-brainer.
>
> > Solving the mailing list 'problem' in a way that requires me to switch to
> > gmail (or some other large scale provider) to get my list mail delivered
> is
> > worse than no solution at all for me.
>
> Obviously. This is not being proposed, see the comments about about
> vendors/developers and reputation data providers.
>
> - Roland
> ___
> 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] introduction to the list-virtual server & mailman questions

[Franck Martin via dmarc-discuss]

Some MTAs are known to break DKIM when doing a simple forwarding. Your
failure reports may give you enough information to know what is happening
at some IPs.

On Sat, Feb 13, 2016 at 3:34 AM, Ben Greenfield via dmarc-discuss <
dmarc-discuss@dmarc.org> wrote:

> Hey All,
>
> Sorry I didn’t not realize what the question might touch off. I have been
> following the discussion and watching my traffic and I have come up with
> this theory.
>
> Looking over my reports I see I get 100% DMARC & SPF coverage with only
> 71% DKIM coverage.
> I’m assuming the DKIM coverage loss represents traffic to list-servs
> rather then a configuration issue on my end.
>
> Is that Plausible.
>
>
> Thanks,
>
> Ben
>
> > On Feb 7, 2016, at 1:10 PM, Al Iverson via dmarc-discuss <
> dmarc-discuss@dmarc.org> wrote:
> >
> > The mailing list question can be a bit tricky. Yeah, the DKIM
> > signature is supposed to transport just fine, unless your MLM rewrites
> > any header or content that breaks the signature. And when you deal
> > with that, eventually you're going to run into list subscribers whose
> > posts get rejected by some other subscribers, due to the poster's
> > domain having a P=reject DMARC policy.
> >
> > I would say there's not a clear consensus on how best to handle
> > mailing lists in a DKIM+DMARC world. A bunch of email folks are
> > working on a standard called Authenticated Received Chain (ARC) that
> > would in theory help to address issues with mailing lists. (See
> > http://arc-spec.org/ ). But, we're a ways from being able to call that
> > a solution.
> >
> > I'm a mailing list operator myself, at probably about the same level
> > you are. (Instead of Mailman, I run a custom MLM that I wrote myself,
> > mostly as a programming exercise.) What I have chosen to do is strip
> > an existing DKIM signature, rewrite the from address if it appears to
> > be a domain that has a restrictive DMARC policy, and then sign it with
> > DKIM as the list domain. This works well for me, but not everybody
> > agrees that it's the best path. I'm not the only one to have done
> > something similar; Yahoo Groups, Google Groups Mail-list.com and
> > OnlineGroups.net all send as the group instead of as the poster either
> > all the time or as needed; and mailman can be configured similarly.
> >
> > Here's a link to an overview of the various issues in play for mailing
> > lists, and info on what I and others have chosen to do to address it.
> > http://www.spamresource.com/2015/02/dmarc-mailing-lists-roundup.html
> >
> > Here's where to go to learn more about what you can do with Mailman:
> > http://wiki.list.org/DEV/DMARC
> >
> > Note: There will probably be at least one really angry reply to this
> > post telling me how horrible this is and that I broke mailing lists.
> > It'll be a rehash of an argument from more than a year ago. Truth be
> > told, somebody else broke mailing lists; this is just how I personally
> > decided to implement a fix that seems to work well for me. YMMV.
> >
> > Regards,
> > Al Iverson
> >
> > --
> > Al Iverson - Minneapolis - (312) 275-0130
> > Simple DNS Tools since 2008: xnnd.com
> > www.spamresource.com & aliverson.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)
>
___
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 reports

[Franck Martin via dmarc-discuss]

State here the bugs you find, we are all ears...

On Thu, Feb 11, 2016 at 9:59 PM, Peter Bowen via dmarc-discuss <
dmarc-discuss@dmarc.org> wrote:

> Thanks, that is really helpful.
>
> It would be really nifty to add a “DMARC 1.0 compliance” percentage next
> to each sender.  I’m seeing lots of reports that don’t follow the XML
> format defined in the RFC.
>
> Thanks,
> Peter
>
> On Feb 10, 2016, at 12:35 PM, Matt Vernhout 
> wrote:
>
> This is a fairly good list of potential DMARC senders:
> https://dmarcian.com/dmarc-status/
>
> Cheers,
>
> ~
> *MATT VERNHOUT*
> Founder, Editor
>
> EmailKarma.net 
> It's not the size of your list, it's how you use it!
>
> My profiles:  
>   
>
>
> On Wed, Feb 10, 2016 at 2:44 PM, Peter Bowen via dmarc-discuss <
> dmarc-discuss@dmarc.org> wrote:
>
>> Does anyone maintain a list of receivers known to send DMARC reports?  I
>> enabled DMARC reporting for a domain we use for sending and have gotten
>> reports so far from 126.com, AOL, Belgacom, CapitalOne, Cisco, Comcast,
>> FastMail, Google, Infor, Microsoft, mail.ru, NetEase (163.com), QQ,and
>> Yahoo.
>>
>> From these reports, I’ve seen a number of different variations that do
>> not follow the XML Schema in RFC 7489.  I know there is the DMARC WG at
>> IETF, but I haven’t seen any updates on the core spec, so I’m hoping
>> someone implementing DMARC may have sorted out what is considered
>> acceptable.
>>
>> Thanks,
>> Peter
>> ___
>> 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)
>
___
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

[Franck Martin via dmarc-discuss]

On Wed, Feb 10, 2016 at 7:06 PM, Steve Atkins via dmarc-discuss <
dmarc-discuss@dmarc.org> wrote:

>
> > On Feb 10, 2016, at 6:37 PM, Roland Turner via dmarc-discuss <
> dmarc-discuss@dmarc.org> wrote:
> >
> > John Levine wrote:
> >
> >> How is this different from everyone's favorite alleged mailing list
> >> solution?
> >>
> >> From: Foo list on behalf of Jane Smith 
> > ...
> >> PS: well, other than it's a little more explicit about where the
> >> responsibility lies
> >
> > That is the difference.
> >
> > I'd prefer:
> >
> >From: Foo list [Jane Smith] 
> >CC: Jane Smith 
> >
> > as "on behalf of" is a little too verbose but, yes, making sure that the
> distinction remains generally visible without:
> >
> > - becoming extremely inconvenient (private replies become impossible
> because the author's email address is missing), or
> > - violating the principle of least astonishment[1] (wait, the list
> operator caused my private reply to be routed through his mail-server?)
>
> Given that the important identifier is often the email address (“Which Bob
> are you?”, “Who is your employer?”) I think that any approach that
> intentionally obscures the actual author in that way is less than ideal.
>
> From: Steve Atkins st...@blighty.com 
>
>
Smells like:

From: Paypal Security secur...@paypal.com 

Not sure it is a good idea.
___
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

[Franck Martin via dmarc-discuss]

John, the critic is always easy, stop bullying please.

On Thu, Feb 11, 2016 at 1:58 PM, John Levine  wrote:

> >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

[Franck Martin via dmarc-discuss]

On Mon, Feb 8, 2016 at 4:35 PM, Al Iverson via dmarc-discuss <
dmarc-discuss@dmarc.org> wrote:

> On Mon, Feb 8, 2016 at 1:51 PM, John R Levine via dmarc-discuss
>  wrote:
> >> It is even worse than I thought, you really want to stop efforts in
> >> fighting phish, by muddling the waters between real domains and fake
> ones
> >
> >
> > There's no muddling going on.  dmarc.fail is a real domain that should
> have
> > an excellent reputation since it sends no phish.
>
> I think Franck is right. It is muddying the waters by introducing a
> wholly other domain that has nothing to do with the list or the
> subscriber. Not seeing why anybody would recommend that as a best
> practice.
>
>
>
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.
___
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] I need an advice

[Franck Martin via dmarc-discuss]

My pleasure, now watch out for Business Email Compromise (BEC) and Account
Take Over (ATO). Your domain is hosted via Google Apps, as they use DMARC
to filter incoming emails, now nobody can inject into your system an email
that would look like internal (as per your domain name), this will help a
lot.

On Tue, Feb 9, 2016 at 2:01 AM, Denis Salicetti via dmarc-discuss <
dmarc-discuss@dmarc.org> wrote:

> Hi Franck,
> you were right. After a couple of weeks introducing reject policy, I
> noticed a decrease of Threat/Unknown sources and now I get just a few of
> those. It worked!
>
> Thank you very much.
>
> *Denis Salicetti* 
>
> Avviso di riservatezza  | Inviami messaggi protetti
> 
>
> 2016-01-19 23:13 GMT+01:00 Franck Martin :
>
>> If you report for take down the URLs you get from the failure reports...
>> Also until you moved to p=reject they would not have noticed a decrease in
>> their success rates... Once it is not worth it, they will move to a softer
>> target, or use a different method to achieve their goals.
>>
>> On Mon, Jan 18, 2016 at 3:54 PM, Denis Salicetti via dmarc-discuss <
>> dmarc-discuss@dmarc.org> wrote:
>>
>>> Hi Jacob,
>>> thank you for your right consideration about the increase of the
>>> deployment and implementation of DMARC reporting, because I think for me it
>>> will be useful for a better assessment in future.
>>>
>>> In this particular moment though, DMARC reporting for my domain is more
>>> o less the same of always.
>>>
>>> Best Regards.
>>>
>>> *Denis Salicetti* 
>>>
>>> Avviso di riservatezza  | Inviami messaggi protetti
>>> 
>>>
>>> 15251a1f17561224
>>>
>>> 2016-01-18 16:46 GMT+01:00 Jacob Evans :
>>>
>>> Another thing to consider is the increase of the deployment and
 implementation of dmarc reporting, as more SMTP Servers report spf/dkim
 failures, those numbers will also increase in the report aggregation.

 My $.02
 ~Jake

 Thank You,

 Jacob D. Evans
 Cloud Consultant
 717.417.8324
  
  
 

 --
 *From: *"Denis Salicetti via dmarc-discuss" 
 *To: *"Matt Simerson" 
 *Cc: *"Denis Salicetti via dmarc-discuss" 
 *Sent: *Monday, January 18, 2016 10:36:58 AM
 *Subject: *Re: [dmarc-discuss] I need an advice

 Hi Matt,
 thank you very much for your kind reply.

 Best Regards.

 *Denis Salicetti* 

 Avviso di riservatezza  | Inviami messaggi
 protetti 

 2016-01-17 23:42 GMT+01:00 Matt Simerson :

> This sounds quite "normal" in my experience.
>
> I started using DMARC for exactly this reason, when one of my domains
> experienced increased spoofing attacks. In the years since, I've witnessed
> this scenario play out in a dozen other domains I manage for my clients. 
> In
> every case, deploying DMARC for their domain with p=reject greatly reduces
> the volume of bounces they receive and the reports reveal the vast 
> majority
> of attacks originating in China and smattering of other IPs from around 
> the
> world. Within weeks after deploying DMARC, the attacks on that domain tail
> off and all but one case I've seen, don't recur.
>
> Matt
>
> PS: My same size is too small to draw conclusions but it seems that
> shorter domain names are more likely to be abused.
>
> On Jan 17, 2016, at 2:08 PM, Denis Salicetti via dmarc-discuss <
> dmarc-discuss@dmarc.org> wrote:
>
> Hi Guys,
> I have implemented DMARC for long with p=none rule with a minimal and
> sporadical Threat/Unknown sources, but recently I had to increase to
> p=quarantene and then to p=reject because I'm having a lot
> of Threat/Unknown sources (25% rate).
> It seems that lately my domain is under serious attack. I'm pretty
> sure I have zero impact of my legit email flow because each configuration
> is good, therefore every Threat/Unknown source is not legit (most of all
> from China).
>
> Someone more experienced of me can tell me if this rate is usual? Is
> there something more that I can do to minimize it?
>
> Thank you very much.
>
> *Denis Salicetti* 
>
> Avviso di riservatezza  | Inviami messaggi
> protetti 
> ___
> dmarc-discuss mailing list
> 

Re: [dmarc-discuss] Sub-domain validation

[Franck Martin via dmarc-discuss]

Relaxed alignment means the identifier domain (SPF or DKIM) have the same
organizational domain as the domain in the RFC5322.From.

On Tue, Feb 9, 2016 at 1:36 PM, Brotman, Alexander via dmarc-discuss <
dmarc-discuss@dmarc.org> wrote:

> Hello,
>
> I have a question about how to interpret a message for DMARC validation,
> relating to section 3.1.1, specifically:
>
>To illustrate, in relaxed mode, if a validated DKIM signature
>successfully verifies with a "d=" domain of "example.com", and the
>RFC5322.From address is "ale...@news.example.com", the DKIM "d="
>domain and the RFC5322.From domain are considered to be "in
>alignment".  In strict mode, this test would fail, since the "d="
>domain does not exactly match the FQDN of the address.
>
> We've encountered a situation where a sender has a DMARC record, and
> they've signed the message with "d=sub.example.com", and the 5322 From
> Domain is "example.com".  The record does not specify an adkim value, so
> it should default to relaxed.
>
> I'm reading the above as the "relaxed" selector should apply to "
> sub.example.com" and something like "foo.sub.example.com", but not to "
> example.com".  From the way the above reads, this part of the validation
> should fail as there isn't a valid DKIM signature available for the 5322
> domain.  Is this correct?
>
> Thank you
>
> --
> Alex Brotman
> Engineer, Anti-Abuse
> Comcast
> x5364
>
>
>
> ___
> 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] introduction to the list-virtual server & mailman questions

[Franck Martin via dmarc-discuss]

It is even worse than I thought, you really want to stop efforts in
fighting phish, by muddling the waters between real domains and fake ones

sigh!

On Sun, Feb 7, 2016 at 1:02 PM, John R Levine  wrote:

> mailing list.  For example. mail from mari...@yahoo.com turns into
>>> mari...@yahoo.com.dmarc.fail.
>>>
>>> Except that @yahoo.com.dmarc.fail is not a domain that exists, and will
>> negatively impact the email deliverability.
>>
>
> Why in the world would you say that?  It not only exists, it's DNSSEC
> signed which is more than you can say about linkedin.com.
>
> Forwarding email addresses in yahoo.com.dmarc.com exist for a couple of
> days after someone at the corresponding yahoo.com address sends mail
> through any of my mailing lists, same for any other address in a domain
> with a DMARC policy.
>
> R's,
> John
>
> ; <<>> DiG 9.8.3-P1 <<>> yahoo.com.dmarc.fail mx +dnssec
> ;; global options: +cmd
> ;; Got answer:
> ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 30940
> ;; flags: qr rd ra ad; QUERY: 1, ANSWER: 2, AUTHORITY: 6, ADDITIONAL: 1
>
> ;; OPT PSEUDOSECTION:
> ; EDNS: version: 0, flags: do; udp: 4096
> ;; QUESTION SECTION:
> ;yahoo.com.dmarc.fail.  IN  MX
>
> ;; ANSWER SECTION:
> yahoo.com.dmarc.fail.   3585IN  MX  20 mail1.iecc.com.
> yahoo.com.dmarc.fail.   3585IN  RRSIG   MX 8 2 3600 2016040300
> 20160201054514 58563 dmarc.fail.
> IZIPS60KsnOEFMX/gYo/3o8zzlIzfhFTrmo2IkbKMLWoWQPIAwXLZRDk
> jXXmymrxYSJ1k3yUUVztCSKzDBWFu4WvYiUwpc9NbG3v7DdN1OwUkxcM
> RgjmqjMxwPcQI1RFoJkgPD1V3azJDOV/f73bd4HPimVD5r6SP/s/v3gc 1s8=
>
> ;; AUTHORITY SECTION:
> *.k1602._domainkey.dmarc.fail. 7185 IN  NSECdmarc.fail. TXT RRSIG NSEC
> *.k1602._domainkey.dmarc.fail. 7185 IN  RRSIG   NSEC 8 4 7200
> 2016040300 20160201054514 58563 dmarc.fail.
> Ue/IR/Gdy4DJHsEJgToONRMP9j5Skyf8hxIHCCGPTyNc+URgtJFDpilS
> 21MTC7zuCIt4fIKV8x428VJDzg2fZzMFQNDuMmtvs8aLMVL6TGAfKlVQ
> NjbYowFrS6g5xTFpkm5SdJmNnLreymuVksVFeniO2Td2+bn2Vvr7hzfc iAw=
> dmarc.fail. 1429IN  NS  sdn.iecc.com.
> dmarc.fail. 1429IN  NS  osdn.iecc.com.
> dmarc.fail. 1429IN  NS  light.lightlink.com.
> dmarc.fail. 1429IN  RRSIG   NS 8 2 3600 2016040300
> 20160201054514 58563 dmarc.fail.
> sZOP1+0qp3pCrk0l9VcEivHak4+v2I32jp9m6iysYTO49m6s6qadiyIy
> I3O21vr4Tk5V+XoN9F/zaIctT4nvDH2mIiDN24cB2uGb05zRg809ars5
> WqOOBCBkYiKJUNi95LmZ0W2VCXqVwTxEYLC4r9EFoBGEm/dloDcWVjG7 Z6A=
>
> ;; Query time: 0 msec
> ;; SERVER: 192.168.80.2#53(192.168.80.2)
> ;; WHEN: Sun Feb  7 15:57:10 2016
> ;; MSG SIZE  rcvd: 707
>
___
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

[Franck Martin via dmarc-discuss]

On Sun, Feb 7, 2016 at 12:22 PM, John Levine via dmarc-discuss <
dmarc-discuss@dmarc.org> wrote:

> In article 

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

[Franck Martin via dmarc-discuss]

This is not the point

On Sun, Feb 7, 2016 at 11:43 AM, Scott Kitterman via dmarc-discuss <
dmarc-discuss@dmarc.org> wrote:

> 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.
>
> Scott K
>
> On Sunday, February 07, 2016 11:14:12 AM Franck Martin via dmarc-discuss
> wrote:
> > ARC will help, but there are many mailing lists that don't have DKIM or
> > even SPF. So even if ARC is available tomorrow, it may take years before
> > mailing lists adopt any solution. So someone will have to make a stand,
> to
> > get operators to deploy something.
> >
> > On Sun, Feb 7, 2016 at 10:10 AM, Al Iverson via dmarc-discuss <
> >
> > dmarc-discuss@dmarc.org> wrote:
> > > The mailing list question can be a bit tricky. Yeah, the DKIM
> > > signature is supposed to transport just fine, unless your MLM rewrites
> > > any header or content that breaks the signature. And when you deal
> > > with that, eventually you're going to run into list subscribers whose
> > > posts get rejected by some other subscribers, due to the poster's
> > > domain having a P=reject DMARC policy.
> > >
> > > I would say there's not a clear consensus on how best to handle
> > > mailing lists in a DKIM+DMARC world. A bunch of email folks are
> > > working on a standard called Authenticated Received Chain (ARC) that
> > > would in theory help to address issues with mailing lists. (See
> > > http://arc-spec.org/ ). But, we're a ways from being able to call that
> > > a solution.
> > >
> > > I'm a mailing list operator myself, at probably about the same level
> > > you are. (Instead of Mailman, I run a custom MLM that I wrote myself,
> > > mostly as a programming exercise.) What I have chosen to do is strip
> > > an existing DKIM signature, rewrite the from address if it appears to
> > > be a domain that has a restrictive DMARC policy, and then sign it with
> > > DKIM as the list domain. This works well for me, but not everybody
> > > agrees that it's the best path. I'm not the only one to have done
> > > something similar; Yahoo Groups, Google Groups Mail-list.com and
> > > OnlineGroups.net all send as the group instead of as the poster either
> > > all the time or as needed; and mailman can be configured similarly.
> > >
> > > Here's a link to an overview of the various issues in play for mailing
> > > lists, and info on what I and others have chosen to do to address it.
> > > http://www.spamresource.com/2015/02/dmarc-mailing-lists-roundup.html
> > >
> > > Here's where to go to learn more about what you can do with Mailman:
> > > http://wiki.list.org/DEV/DMARC
> > >
> > > Note: There will probably be at least one really angry reply to this
> > > post telling me how horrible this is and that I broke mailing lists.
> > > It'll be a rehash of an argument from more than a year ago. Truth be
> > > told, somebody else broke mailing lists; this is just how I personally
> > > decided to implement a fix that seems to work well for me. YMMV.
> > >
> > > Regards,
> > > Al Iverson
> > >
> > > --
> > > Al Iverson - Minneapolis - (312) 275-0130
> > > Simple DNS Tools since 2008: xnnd.com
> > > www.spamresource.com & aliverson.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)
>
___
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

[Franck Martin via dmarc-discuss]

ARC will help, but there are many mailing lists that don't have DKIM or
even SPF. So even if ARC is available tomorrow, it may take years before
mailing lists adopt any solution. So someone will have to make a stand, to
get operators to deploy something.

On Sun, Feb 7, 2016 at 10:10 AM, Al Iverson via dmarc-discuss <
dmarc-discuss@dmarc.org> wrote:

> The mailing list question can be a bit tricky. Yeah, the DKIM
> signature is supposed to transport just fine, unless your MLM rewrites
> any header or content that breaks the signature. And when you deal
> with that, eventually you're going to run into list subscribers whose
> posts get rejected by some other subscribers, due to the poster's
> domain having a P=reject DMARC policy.
>
> I would say there's not a clear consensus on how best to handle
> mailing lists in a DKIM+DMARC world. A bunch of email folks are
> working on a standard called Authenticated Received Chain (ARC) that
> would in theory help to address issues with mailing lists. (See
> http://arc-spec.org/ ). But, we're a ways from being able to call that
> a solution.
>
> I'm a mailing list operator myself, at probably about the same level
> you are. (Instead of Mailman, I run a custom MLM that I wrote myself,
> mostly as a programming exercise.) What I have chosen to do is strip
> an existing DKIM signature, rewrite the from address if it appears to
> be a domain that has a restrictive DMARC policy, and then sign it with
> DKIM as the list domain. This works well for me, but not everybody
> agrees that it's the best path. I'm not the only one to have done
> something similar; Yahoo Groups, Google Groups Mail-list.com and
> OnlineGroups.net all send as the group instead of as the poster either
> all the time or as needed; and mailman can be configured similarly.
>
> Here's a link to an overview of the various issues in play for mailing
> lists, and info on what I and others have chosen to do to address it.
> http://www.spamresource.com/2015/02/dmarc-mailing-lists-roundup.html
>
> Here's where to go to learn more about what you can do with Mailman:
> http://wiki.list.org/DEV/DMARC
>
> Note: There will probably be at least one really angry reply to this
> post telling me how horrible this is and that I broke mailing lists.
> It'll be a rehash of an argument from more than a year ago. Truth be
> told, somebody else broke mailing lists; this is just how I personally
> decided to implement a fix that seems to work well for me. YMMV.
>
> Regards,
> Al Iverson
>
> --
> Al Iverson - Minneapolis - (312) 275-0130
> Simple DNS Tools since 2008: xnnd.com
> www.spamresource.com & aliverson.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] I need an advice

[Franck Martin via dmarc-discuss]

If you report for take down the URLs you get from the failure reports...
Also until you moved to p=reject they would not have noticed a decrease in
their success rates... Once it is not worth it, they will move to a softer
target, or use a different method to achieve their goals.

On Mon, Jan 18, 2016 at 3:54 PM, Denis Salicetti via dmarc-discuss <
dmarc-discuss@dmarc.org> wrote:

> Hi Jacob,
> thank you for your right consideration about the increase of the
> deployment and implementation of DMARC reporting, because I think for me it
> will be useful for a better assessment in future.
>
> In this particular moment though, DMARC reporting for my domain is more o
> less the same of always.
>
> Best Regards.
>
> *Denis Salicetti* 
>
> Avviso di riservatezza  | Inviami messaggi protetti
> 
>
> 15251a1f17561224
>
> 2016-01-18 16:46 GMT+01:00 Jacob Evans :
>
> Another thing to consider is the increase of the deployment and
>> implementation of dmarc reporting, as more SMTP Servers report spf/dkim
>> failures, those numbers will also increase in the report aggregation.
>>
>> My $.02
>> ~Jake
>>
>> Thank You,
>>
>> Jacob D. Evans
>> Cloud Consultant
>> 717.417.8324
>>  
>>  
>> 
>>
>> --
>> *From: *"Denis Salicetti via dmarc-discuss" 
>> *To: *"Matt Simerson" 
>> *Cc: *"Denis Salicetti via dmarc-discuss" 
>> *Sent: *Monday, January 18, 2016 10:36:58 AM
>> *Subject: *Re: [dmarc-discuss] I need an advice
>>
>> Hi Matt,
>> thank you very much for your kind reply.
>>
>> Best Regards.
>>
>> *Denis Salicetti* 
>>
>> Avviso di riservatezza  | Inviami messaggi protetti
>> 
>>
>> 2016-01-17 23:42 GMT+01:00 Matt Simerson :
>>
>>> This sounds quite "normal" in my experience.
>>>
>>> I started using DMARC for exactly this reason, when one of my domains
>>> experienced increased spoofing attacks. In the years since, I've witnessed
>>> this scenario play out in a dozen other domains I manage for my clients. In
>>> every case, deploying DMARC for their domain with p=reject greatly reduces
>>> the volume of bounces they receive and the reports reveal the vast majority
>>> of attacks originating in China and smattering of other IPs from around the
>>> world. Within weeks after deploying DMARC, the attacks on that domain tail
>>> off and all but one case I've seen, don't recur.
>>>
>>> Matt
>>>
>>> PS: My same size is too small to draw conclusions but it seems that
>>> shorter domain names are more likely to be abused.
>>>
>>> On Jan 17, 2016, at 2:08 PM, Denis Salicetti via dmarc-discuss <
>>> dmarc-discuss@dmarc.org> wrote:
>>>
>>> Hi Guys,
>>> I have implemented DMARC for long with p=none rule with a minimal and
>>> sporadical Threat/Unknown sources, but recently I had to increase to
>>> p=quarantene and then to p=reject because I'm having a lot
>>> of Threat/Unknown sources (25% rate).
>>> It seems that lately my domain is under serious attack. I'm pretty sure
>>> I have zero impact of my legit email flow because each configuration is
>>> good, therefore every Threat/Unknown source is not legit (most of all from
>>> China).
>>>
>>> Someone more experienced of me can tell me if this rate is usual? Is
>>> there something more that I can do to minimize it?
>>>
>>> Thank you very much.
>>>
>>> *Denis Salicetti* 
>>>
>>> Avviso di riservatezza  | Inviami messaggi protetti
>>> 
>>> ___
>>> 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)
>>
>
>
> ___
> 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] A bit quiet?

[Franck Martin via dmarc-discuss]

I think ARC is making it clear it does not provide a chain of trust but a
custodial chain.

Assessing the trust of this custodial chain is left as an exercise to the
implementer :P

Seriously, a very simple system, is to extract all the domains in the chain
and see if any is on a blocklist (including newly observed domains).

On Sat, Oct 24, 2015 at 3:42 AM, J. Gomez via dmarc-discuss <
dmarc-discuss@dmarc.org> wrote:

> On Saturday, October 24, 2015 4:54 AM [GMT+1=CET], Scott Kitterman via
> dmarc-discuss wrote:
>
> > On October 23, 2015 8:37:06 PM EDT, John Levine 
> > wrote:
> > > > From a DMARC perspective, if you know the sender is trustworthy,
> > > > you do a local override.  ARC doesn't
> > > > seem to be needed for that.
> > >
> > > I have many of the same questions you do, but it is my impression
> > > that a surprising number of lists behave fine for a long time, then
> > > some bad guy starts pumping spam through it by impersonating one of
> > > the subscribers.
> > >
> > > ARC should be helpful in that perhaps non-exotic situation.
> >
> > Could be.  I certainly don't claim it's not potentially useful.  My
> > concern is that it seems to be marketed as a solution to the DMARC
> > mailing list problem and as far as I can tell, its potential utility
> > is orthogonal to that.
>
> Ok, you said "from a DMARC perspective, if you know the sender is
> trustworthy, you do a local override". But imagine big ESP "A" with
> hundreds of thousands of users who may subscribe to all kinds of mailing
> lists of which mailing lists you --as big ESP "B"-- had no previous
> knowledge and on which you have no a-priori trust.
>
> In that scenario, when you as big ESP "B" receive email from such mailing
> lists addressed to your users, you don't know whether the sender (i.e., the
> mailing list) is trustworthy because you didn't know anything about him
> until now, so you cannot do a local override of DMARC in an automated and
> safe way.
>
> But if the big ESP "A" user sent a DKIM signed message to that list, and
> that list added a ARC seal to the message when it forwarded said message to
> the list's subscribers, then you --as big ESP "B" and as recipient of said
> message-- could verify that it is true that said user from big ESP "A"
> indeed sent that original email addressed to the list, and if the ARC chain
> is verifiable and goes back to someone you trust then you could begin to
> put some trust also in the other end of the ARC chain (on its latest
> iteration), and therefore do a local override of DMARC in an automated and
> safe way even with email received from senders your didn't know were
> trustworthy.
>
> Am I too off base?
>
> Regards,
> J.Gomez
>
>
> ___
> 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] A bit quiet?

[Franck Martin via dmarc-discuss]

The fun is moving to ARC

https://dmarc.org/2015/10/global-mailbox-providers-deploying-dmarc-to-protect-users/

On Thu, Oct 22, 2015 at 8:51 AM, Mark Rousell via dmarc-discuss <
dmarc-discuss@dmarc.org> wrote:

> Is it just me or was the last post on here really on 5th October?
>
> --
> Mark Rousell
>
>
>
>
>
> ___
> 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] A bit quiet?

[Franck Martin via dmarc-discuss]

On Thu, Oct 22, 2015 at 12:36 PM, Andrew Beverley <a...@simplelists.com>
wrote:

> On Thu, 2015-10-22 at 10:19 -0700, Franck Martin via dmarc-discuss
> wrote:
> > The fun is moving to ARC
> >
> >
> https://dmarc.org/2015/10/global-mailbox-providers-deploying-dmarc-to-protect-users/
>
> Sad to see that Gmail plan to move to p=reject
>
> It will be interesting to see what the scammers come up with when that
> happens.
>
> Let's hope ARC delivers.
>
> Hopefully you can help achieve this goal with the resources at your
disposition.
___
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] wanted: rfc number

[Franck Martin via dmarc-discuss]

On Tue, Sep 29, 2015 at 12:15 PM, A. Schulze via dmarc-discuss <
dmarc-discuss@dmarc.org> wrote:

>
> Alec Peterson via dmarc-discuss:
>
> Why force the report generator to do something that could be done when the
>> report is received, if desired?
>>
>
> because
> - the MTA already did the rDNS job
> - I send the failure reports to myself. I still "see" the Source-IP field
> which has not so much information...
>

 Add the smtp.helo from SPF in the authentication results, this is the next
best thing. More often than not it matches the rDNS.
___
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 reports and rfc3834#5 The Auto-Submitted header field

[Franck Martin via dmarc-discuss]

seems like a good idea

On Wed, Aug 26, 2015 at 5:30 AM, Jacob Evans via dmarc-discuss 
dmarc-discuss@dmarc.org wrote:

 Hey All,

 Are we requesting that an auto generated/auto submitted header be included
 in these reports?



 This will remove things like OOF Bounces and auto responders. (which will
 just help patch misuse of the DMARC record itself as I would expect reports
 should go to parsers, not users.)



 Just another ab/user,

 Jake

 --

 This message contains information that may be confidential and privileged.
 Unless you are the addressee (or authorized to receive for the addressee),
 you may not use, copy, print or disclose to anyone the message or any
 information contained in the message. If you have received this e-mail in
 error, please advise the sender by reply and delete the message. Thank you.


 -- Forwarded message --
 From: Elizabeth Zwicky zwi...@yahoo-inc.com
 To: SpamAdmins spamadm...@higherinfogroup.com
 Cc:
 Date: Wed, 26 Aug 2015 04:03:10 +
 Subject: Auto Response: Report Domain: yahoo.com Submitter: Report-ID:
 yahoo.com-1440561717@
 I am on vacation and will be back in the office on August 31st.

 Elizabeth Zwicky

 ___
 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] dmarc gogole attachments seen as executable

[Franck Martin via dmarc-discuss]

indeed, but seems the filter is looking for .com anywhere in the filename
string, rather than at the end... I say bad design.

in DMARC filenames end up with .xml, .zip or .gzip

On Tue, Aug 25, 2015 at 11:05 AM, Dave Warren via dmarc-discuss 
dmarc-discuss@dmarc.org wrote:

 On 2015-08-25 09:56, John Levine via dmarc-discuss wrote:

 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.



 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. .COM is possibly the worst of the lot because of the one-two
 punch that users don't associate it with executable code (it's only
 supported for legacy reasons), and because users do associate it with the
 web in general. It's half a technical attack and half a social attack, so
 no, malware cannot simply use a different name to get the same result.

 Malware detection and blocking is really more of an art than a science,
 but looking for suspicious names is actually one of the things that has
 stood the test of time vs many other techniques simply because there is a
 limited set of extensions that are treated as executable code by Windows,
 and there are very few cases when sending executable code by email is a
 good idea.

 At the same time, I'd expect someone at the postmaster level to be able to
 configure exceptions so that they can receive abuse reports at appropriate
 abuse@ and postmaster@ addresses which may include bad content of a
 variety of types, and similarly, I'd expect DMARC addresses to be treated
 similarly, so even if globally changing the filenames were possible, I
 wouldn't actually recommend doing it.

 --
 Dave Warren
 http://www.hireahit.com/
 http://ca.linkedin.com/in/davejwarren



 ___
 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] dmarc gogole attachments seen as executable

[Franck Martin via dmarc-discuss]

Note that the failure reports contains even more information that will
trigger the filters, therefore both addresses (rue and ruf) should be set
up to allow such reports to come in. Fix your filters would be my answer.

On Sun, Aug 23, 2015 at 11:35 AM, jotest via dmarc-discuss 
dmarc-discuss@dmarc.org wrote:

 Sorry for sending it again i did became a reject before.

 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.

 regards


 ___
 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] [Newbie warning] Both spf and dkim?

[Franck Martin via dmarc-discuss]

DKIM fails for 0.5% of cases when it should not fail, cause the protocol
is really complex and until DMARC such bugs were hard to find...

SPF is an easy protocol, not many bugs... however does not work with DMARC
when forwarding emails (the aligned part that is).

So for p=none you don't need to do SPF and DKIM, collect the reports...

for p=quarantine and p=reject, implementing DKIM only could be ok, if you
are ok with the number of fails that SPF could have saved.

On Wed, Aug 12, 2015 at 10:46 AM, Carlos P via dmarc-discuss 
dmarc-discuss@dmarc.org wrote:

 Hello,


 I am new to DMARC and have a question: It is necesary to setup both SPF
 and DKIM in order to quarantine or reject. I can not tell that from the
 RFC[1] neither searching this list, but there are some other places [2][3]
 that say so.


 Is not finding a DKIM or SPF record considered a failure by itself when
 p!=none?

 If so, I would like to know the rationale behind. Is it to make it a
 little more resilient to small and trascient mistakes?

 Thank you


 [1] http://tools.ietf.org/html/rfc7489

 2.  Receivers compare the RFC5322.From address in the mail to the SPF
 and DKIM results, if present, and the DMARC policy in DNS.

 later

 Identifier Alignment:  When the domain in the RFC5322.From address
 matches a domain validated by SPF or DKIM (or both), it has
 Identifier Alignment

 [2] https://support.google.com/a/answer/2466563

 Important: Before creating a DMARC record for your Google Apps domain,
 you must first set up DKIM authentication. If you fail to set up DKIM
 first, email from services such as Google Calendar will fail mail
 authentication and will not be delivered to users.


 [3]
 http://blog.endpoint.com/2014/04/spf-dkim-and-dmarc-brief-explanation.html

 DMARC can (and will) break your mail flow if you don't set up both SPF
 and DKIM before changing DMARC policy to anything above 'none'.

 --

 Carlos Pantelides
 @dev4sec
 seguridad-agile.blogspot.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] am not getting any rua reports for a domain

[Franck Martin via dmarc-discuss]

check https://dmarcian.com/dmarc-inspector/sb.intelli-shop.com for errors
and warnings.
___
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

[Franck Martin via dmarc-discuss]

http://digwebinterface.com/?hostnames=_dmarc.sb.mumble.comtype=TXTuseresolver=8.8.4.4ns=authnameservers=

Is telling me you do not have any DMARC record form sb.mumble.com

Check also https://dmarcian.com/dmarc-inspector/sb.mumble.com

On Wed, Jul 15, 2015 at 12:47 PM, Steven M Jones via dmarc-discuss 
dmarc-discuss@dmarc.org wrote:

 On 07/15/2015 12:18, Eric S Johansson via dmarc-discuss wrote:

 I'm acting as a third party mailer for one of my customers.  ... but from
 my customer's domain, I get nothing even though the setup looks identical.


 So your issue is that you aren't receiving any aggregate reports for the
 domain mumble.com at the mailbox sbmumblecom_...@my.mailservice.com
 right?


  all mail messages are signed from sb.mumble.com and sent from
 my.mailservice.com and google says all is well for dkim/spf. messages
 are from u...@mumble.com.


 Do you mean that the RFC5322.From domain for the message traffic in
 question is mumble.com, but all your DMARC and DKIM records are using 
 sb.mumble.com -- as quoted below:


  here are the records via dig with domain redacted (and hopefully not fat
 fingered)

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

 the authorizing record is:

 mumble.com._report._dmarc.my.mailservice.com.185 IN TXT v=DMARC1


 any suggestions on what I'm missing?


 Message traffic using an RFC5322.From of sb.mumble.com would use a
 DMARC record published for the Organizational Domain mumble.com, but
 the reverse doesn't work.

 I think you want to either change the RFC5322.From domain in the messages
 being sent to sb.mumble.com, or publish a DMARC record for mumble.com.

 Hopefully I haven't missed something obvious...

 --Steve.


 ___
 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] Mail delivery failed: returning message to sender

[Franck Martin via dmarc-discuss]

I alerted Steve Jones. He should get it fixed soon

On the broader question, send aggregates and failure report from dedicated
IPs, it is safer.

On Thu, Jul 9, 2015 at 9:00 AM, Al Iverson via dmarc-discuss 
dmarc-discuss@dmarc.org wrote:

 Aha, that makes sense now. Thanks.

 On Thu, Jul 9, 2015 at 10:53 AM, Tim Draegen t...@eudaemon.net wrote:
  On Jul 9, 2015, at 11:41 AM, Al Iverson via dmarc-discuss 
 dmarc-discuss@dmarc.org wrote:
 
  I agree that it looks like a bum forwarder setup from what you've
  posted. Forgive the dumb question -- why are you sending reports to
  dmarc.org?
 
 
  No, this is just where dmarc.org is asking for reports to go.
 
  % dig _dmarc.dmarc.org txt
  v=DMARC1\; p=none\; pct=100\; rua=mailto:repo...@dmarc.org\;
 ruf=mailto:repo...@dmarc.org;
 
  Indeed, it looks like a broken config on dmarc.org's end.  They've been
 redoing a lot of their stuff now that it is an official non-profit effort.
 
  -= Tim
 
 



 --
 Al Iverson | Minneapolis, MN | (312) 725-0130
 aliverson.com | spamresource.com | @aliverson
 ___
 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] exim rejecting gmail DMARC reports

[Franck Martin via dmarc-discuss]

You are supposed to ship the aggregate report as a gzip attachment, with
the gzip extension. (zip will work too, but we made it obsolete).

On Thu, Jul 9, 2015 at 4:46 AM, Chad Henry via dmarc-discuss 
dmarc-discuss@dmarc.org wrote:

 I'm receiving the following message from exim when receiving Gmail DMARC
 reports. Hotmail and Yahoo reports are delivered without issue.



 A message that you sent could not be delivered to one or more of its

 recipients. This is a permanent error. The following address(es) failed:



   aggdmarc@domain-redacted.com

 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



 Thanks,

 Chad



 ___
 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] dmarc record added but no reports received

[Franck Martin via dmarc-discuss]

On Jan 15, 2015, at 2:45 AM, Constantino Antunes via dmarc-discuss 
dmarc-discuss@dmarc.org wrote:

 Hello,
 
 I have set up dmarc for a couple of domains, and confirmed they are correct 
 using the dmarcian inspector:
 https://dmarcian.com/dmarc-inspector/theticketsellers.co.uk
 https://dmarcian.com/dmarc-inspector/ttscrew.co.uk
 
 A couple days later, I sent spoof e-mails (using deadfake.com) to my personal 
 gmail account, in an attempt to cause a report. But until today (a week since 
 my last test) I have not received any reports.
 
 Can you please help me understand why I am not receiving any reports?

http://www.dmarc.org/faq.html#s_11


signature.asc
Description: Message signed with OpenPGP using GPGMail
___
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] inconsistent policy_published

[Franck Martin via dmarc-discuss]

On Dec 5, 2014, at 1:29 PM, John Bodek via dmarc-discuss 
dmarc-discuss@dmarc.org wrote:

 Ah ha.  Looks like the Google support guide gives a bad example.  Now 
 switching over to dmarc.org for future reference :)
 


try dmarcian.com to validate your record



signature.asc
Description: Message signed with OpenPGP using GPGMail
___
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] Upgrade your MS-Exchange 2013 to Cumulative Update 6

[Franck Martin via dmarc-discuss]

http://support.microsoft.com/kb/2993556
---
Sender's DKIM signature is broken in an Exchange Server 2013 environment

This issue occurs because Microsoft Exchange changes the headers of a message, 
and this breaks the DomainKeys Identified Mail (DKIM) signature.

To resolve this issue, install the following cumulative update:
2961810 Cumulative Update 6 for Exchange Server 2013

—
I’d like to personally thank Terry Zink for making this fix happen.


signature.asc
Description: Message signed with OpenPGP using GPGMail
___
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 Check issue on Google Reports

[Franck Martin via dmarc-discuss]

Check
https://dmarcian.com/spf-survey/prodest.es.gov.br
There is a warning and the a: is redundant anyhow, I would just suppress it. No 
need to add an extra DNS query.

your authoritative servers seems fine:
http://www.digwebinterface.com/?hostnames=prodest.es.gov.brtype=TXTshowcommand=oncolorize=onuseresolver=8.8.4.4ns=authnameservers=

Otherwise, yes, Gmaill should not fail that often on this SPF record. 

On Sep 17, 2014, at 8:59 PM, Daniel Brito via dmarc-discuss 
dmarc-discuss@dmarc.org wrote:

 Hi Jesper,
 
 The statement a accept this sintax : a:domain/prefix-length. You 
 could check on the this page: http://www.openspf.org/SPF_Record_Syntax
 
 Also, it is possible to check the spf record on some internet tools. I 
 particularly use this: http://vamsoft.com/support/tools/spf-policy-tester. 
 
 I will continue analyzing the dmarc report until i feel confident to use on 
 100% of the mesagens.
 
 
 Regards,
 Daniel Brito
 
 
 On Wed, Sep 17, 2014 at 2:13 PM, Jesper Knudsen 
 jesper.knud...@scanmailx.com wrote:
 Do not know whether its the reason but your SPF record looks a little odd to 
 me.
 
  
 
 v=spf1 a:ironport.mail.es.gov.br/24 ip4:201.62.46.0/24 ip4:201.62.33.0/24 ~all
 
  
 
 The “a:” statement should not to my knowledge have a “/24” – maybe Google is 
 just getting choked with that.
 
  
 
 Regards,
 
 Jesper
 
  
 
 From: dmarc-discuss [mailto:dmarc-discuss-boun...@dmarc.org] On Behalf Of 
 Daniel Brito via dmarc-discuss
 Sent: 16. september 2014 15:56
 To: João Oliveirinha
 Cc: dmarc-discuss@dmarc.org
 Subject: Re: [dmarc-discuss] SPF Check issue on Google Reports
 
  
 
 Hi, thanks for all.
 
  
 
 I verified all the suggestions, but everything is correctly. I don´t have 
 IPV6 and the DNS servers return the same results.
 
 Today, i received this report from google:
 
  
 
 record
 
 row
 
   source_ip201.62.46.25/source_ip
 
   count21/count
 
 .
 
 .
 
 .
 
   spf
 
 domainprodest.es.gov.br/domain
 
 resultpass/result
 
   /spf
 
 /auth_results
 
 /record
 
   
 
 record
 
 row
 
   source_ip201.62.46.25/source_ip
 
   count1/count
 
 .
 
 .
 
 .
 
   spf
 
 domainprodest.es.gov.br/domain
 
 resultfail/result
 
   /spf
 
 /auth_results
 
 /record
 
   
 
 record
 
 row
 
   source_ip201.62.46.25/source_ip
 
   count30/count
 
 .
 
 .
 
 .
 
   spf
 
 domainprodest.es.gov.br/domain
 
 resultpass/result
 
   /spf
 
 /auth_results
 
 /record
 
  
 
 record
 
 row
 
   source_ip201.62.46.25/source_ip
 
   count7/count
 
 .
 
 .
 
 .
 
   spf
 
 domainprodest.es.gov.br/domain
 
 resultfail/result
 
   /spf
 
 /auth_results
 
 /record
 
 ...
 
  
 
 This information is in one report aggregate, all this messages have passed in 
 DKIM verification, so this not impact me. But if it is not a error in Google 
 servers, it could be some miss configuration here.
 
 The DMARC registes is : v=DMARC1; p=reject; sp=none; pct=70; 
 rua=mailto:dm...@prodest.es.gov.br;
 
  
 
 Like João Oliveirinha said, it is a minimum percentage of the email that 
 fails on SPF and only happen on google report's.
 
  
 
  
 
 Best Regards,
 
 Daniel Brito
 
  
 
 On Mon, Sep 15, 2014 at 7:00 PM, João Oliveirinha dmarc-discuss@dmarc.org 
 wrote:
 
 I am also seeing some problems with SPF verification by google servers 
 recently.
 
  
 
 The majority of cases are fail spf responses, but some are permerrors. 
 Which is strange. I haven't changed my dns records in some time, and my dns 
 provider is Cloudflare. 
 
  
 
 Either way, this is only ~3% of the emails in the least week, for instance.
 
  
 
 
 
 -- 
 
  
 
 
 
 João Oliveirinha / Senior Data Scientist
 +351 91 322 43 52/ joao.oliveiri...@feedzai.com (PGP)
 
 Feedzai SA Office: +351 211 985 635
 Edifício Atlantis, Av. João II, Lote 1.06.2.2, 1990-095 Lisboa, Portugal
 http://www.feedzai.com
 
  
 
  
 
 On Mon, Sep 15, 2014 at 10:13 PM, Dave Warren via dmarc-discuss 
 dmarc-discuss@dmarc.org wrote:
 
 On 2014-09-15 13:55, Al Iverson via dmarc-discuss wrote:
 
 First thing I would look at is, do all of your DNS servers reliably
 return the same results? If you have 3-4 DNS servers and one of them
 doesn't return the right info, this could conceivably cause what you
 are seeing.
 
 
 One other thought, beyond what Al said... Any chance you've started 
 delivering to Google via IPv6, but your SPF only covers your IPv4 IP space?
 
 -- 
 Dave Warren
 http://www.hireahit.com/
 http://ca.linkedin.com/in/davejwarren
 
 
 
 
 ___
 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
 

Re: [dmarc-discuss] DMARC and mailing lists

[Franck Martin via dmarc-discuss]

On Aug 24, 2014, at 3:07 PM, Larry Finch via dmarc-discuss 
dmarc-discuss@dmarc.org wrote:

 
 On Aug 24, 2014, at 4:05 PM, Matt Simerson via dmarc-discuss 
 dmarc-discuss@dmarc.org wrote:
 
 
 On Aug 24, 2014, at 5:18 AM, Nicolás via dmarc-discuss 
 dmarc-discuss@dmarc.org wrote:
 
 Hi!
 
 I'm new to DMARC, I configured it just a bunch of days ago, and even that I 
 think it's a great idea, I'm worried about its limitations over mailing 
 lists. I've read the FAQ about this, and I'm not quite clear about what can 
 I do to avoid DMARC checkings to fail.
 
 On lists you don't manage, there is little you can do besides pester the 
 list operator and ask them to make their list DMARC compatible. But:
 
   1. list operators tend to be change resistant
   2. there are now patches available for most list software to make them 
 DMARC compatible
   3. For unmaintained MLMs, like ezmlm, turning off options like subject 
 prefix and trailers suffices.
   4. ezmlm-idx does have patches
   5. Some of the MLM patches don't rewrite the sender *unless* they detect a 
 p=reject policy
   6. see #1
 
 I'm not going to rehash material from the FAQ but thinking about it from the 
 list operators perspective, why should *they* have to change *their* list so 
 that your silly little anti-phishing security thingy works? (I don't 
 subscribe to that school of thought, but that's frequently the attitude)
 
 
 This is a vast oversimplification. Yes, it is possible to change the way list 
 servers work to pass DMARC. However, doing so creates problems with lists 
 that are set for replies to go to the list, and also makes it harder to 
 identify who the actual sender is. And the requirement that we not add a 
 footer violates the law that says that lists must include opt-out 
 instructions in a footer. But the bigger problem is that it is costly. We run 
 17 lists on L-Soft’s listserv. We use an out of date version that meets our 
 needs. To update to the version that supports DMARC compatibility would cost 
 us about $6,000. We contacted L-Soft, and were told that they would give us a 
 special deal, and only charge us $3,000 if we were willing to bypass 
 maintenance support. Our annual budget to run our Linux virtual server is 
 $275. Our lists are supported by voluntary contributions and managed by 
 volunteer administrators. So our solution is to ban Yahoo and AOL addresses 
 from posting to a list.
 

I understand you may not have budgeted upgrades, but nowadays timely upgrades 
are part of staying secure.

http://www.cvedetails.com/vulnerability-list/vendor_id-69/Lsoft.html


signature.asc
Description: Message signed with OpenPGP using GPGMail
___
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

[Franck Martin via dmarc-discuss]

On Aug 1, 2014, at 10:08 AM, Benny Pedersen s...@forged.junc.eu wrote:

 Authentication-Results: duggi.junc.org/5CA2025C056; dmarc=none 
 header.from=dmarc.org
 
 not solved yet
 

Because your client decided to show you the email I sent you directly rather 
than the one via this mailing list…

Let’s see this one now...



signature.asc
Description: Message signed with OpenPGP using GPGMail
___
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] opendmarc 1.3.0 released

[Franck Martin via dmarc-discuss]

Aim to the opendmarc mailing list if you have questions, but I though I would 
alert people of this release on this list.

http://sourceforge.net/projects/opendmarc/

OPENDMARC RELEASE NOTES

This listing shows the versions of the OpenDMARC package, the date of
release, and a summary of the changes in that release.

1.3.0   2014/07/31
Integrated SPF checking is now available through the new
SPFSelfValidate and SPFIgnoreResults settings.
Feature request #79: Optionally ignore clients that authenticated
using SMTP AUTH.
Fix bug #60, part II: Default AuthservID to the name provided by the
MTA, not the local host name, which is consistent with what
OpenDKIM does.  Suggested by Robbert Klarenbeek.
Fix bug #72: Don't crash when From fields are absent.  Patch from
Andreas Schulze.
Fix bug #74: Change Forensic to Failure just about everywhere
to match the language now being used in the base DMARC
draft.  Note that this also changes some names in the
configuration file.
Fix bug #75: Correct typo in MIME of forensic reports.  Reported by
Julian Mehnle.
Fix bug #76: Repair damage with respect to Authentication-Results
header field selection.  Reported by Todd Lyons.
Fix bug #77: Request quarantine from the MTA during option
negotiation.  Reported by Richard Platel.
Fix bug #78: Add missing newline in forensic report header.
Fix bug #90: Make --with-sql-backend without any value do the
right thing.  Reported by Scott Kitterman.
Fix bug #93: Honor size limits in URIs.  Patch from Tomki Camp.
Make smime and rrvs legal Authentication-Results methods.
Provide better logging when pclose() for a forensic report returns
non-zero.  Problem noted by Michael Nausch.
Add configuration support for internal SPF checks.  Includes hooks in
the milter to check that SPF is configured to do so.
This can use a private SPF implementation or libspf2.
Fix strlcat() and strlcpy() support for Debian.  Patch from Scott
Kitterman.
REPORTS: Feature request #80: Generate aggregate reports on UTC
day boundaries.  Requested by Tomki Camp.
REPORTS: Feature request #84: Optionally expire old data from
lower-growth tables.  Requested by Christoph Steindl.
REPORTS: Fix bug #70: Fix date range generation in reports.  Patch
from Karol Augustin.
REPORTS: Fix bug #82: Fix recording of report timestamp to avoid lost
records.  Reported by Christoph Steindl.
REPORTS: Fix bug #83: When expiring data, truncate the signatures table
if all messages were expired.  Reported by Christoph Steindl.
REPORTS: Fix bug #85: Report subdomain policy.  Patch from
Christoph Steindl.
LIBOPENDMARC: Fix bug #71: Fix rua extraction from DMARC records
Problem noted by Karol Augustin.
LIBOPENDMARC: Added support for milter to perform own spf checks.
Three new files: opendmarc_spf.c, opendmard_spf_dns.c and
test/test_spf.cl, allow integrated SPF support.  Support for
use of libspf2 is also provided.



signature.asc
Description: Message signed with OpenPGP using GPGMail
___
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

[Franck Martin via dmarc-discuss]

Any receiver may decide to override the sender policy. There is a method to do 
that and report it in aggregate reports. A receiver would do it, when you have 
a particularly troublesome big forwarder and when too many of your users would 
complain of not receiving such emails anymore.

The solution: identify the forwarder and tell them to not break DKIM when 
forwarding. If they don’t get it, may be don’t email the forwarder… (better 
said than done).

On Jul 31, 2014, at 3:31 PM, Norman, Jean Marie via dmarc-discuss 
dmarc-discuss@dmarc.org wrote:

 Has anyone experienced unauthenticated emails being delivered to Google 
 recipients despite having a DMARC policy (quarantine or reject) in place? We 
 have seen evidence that unauthenticated emails (not passing both SPF and 
 DKIM) are being delivered to Google, despite a DMARC policy, when messages 
 pass through a ‘forwarder’, as noted by Google. We are trying to better 
 understand this behavior and whether or not anyone has found a solution? Any 
 insight or recommendations would be appreciated.
  
 Thanks,
  


signature.asc
Description: Message signed with OpenPGP using GPGMail
___
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

[Franck Martin via dmarc-discuss]

On Jul 31, 2014, at 4:37 PM, Steve Atkins via dmarc-discuss 
dmarc-discuss@dmarc.org wrote:

 
 On Jul 31, 2014, at 3:31 PM, Norman, Jean Marie via dmarc-discuss 
 dmarc-discuss@dmarc.org wrote:
 
 Has anyone experienced unauthenticated emails being delivered to Google 
 recipients despite having a DMARC policy (quarantine or reject) in place? We 
 have seen evidence that unauthenticated emails (not passing both SPF and 
 DKIM) are being delivered to Google, despite a DMARC policy, when messages 
 pass through a ‘forwarder’, as noted by Google. We are trying to better 
 understand this behavior and whether or not anyone has found a solution? Any 
 insight or recommendations would be appreciated.
 
 Several large entities have published inappropriate DMARC records, leading to 
 wanted mail from those entities not being authenticated when it ends up at 
 the recipients inbox. Because of that, Google (and others) are unlikely to 
 blindly follow DMARC policies.
 

None of the large entities have published inappropriate DMARC records. They did 
it knowing exactly the impact and I don’t know any receiver that changed the 
way they process DMARC after such large entities allegedly published such 
records.

It was known for some time that some systems (amongst other use cases), for 
instance, were not keeping the DKIM signature while doing simple forwarding and 
would have to be fixed. Cf 
http://www.it.cornell.edu/services/guides/email/issues.cfm#dmarc which uses 
MS-Exchange. Microsoft should fix this problem in an upcoming release 
(https://www.mail-archive.com/dmarc-discuss@dmarc.org/msg01621.html), 
meanwhile...


signature.asc
Description: Message signed with OpenPGP using GPGMail
___
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

[Franck Martin via dmarc-discuss]

If you look at the spec, there is a strong recommendation to have it this way:

http://tools.ietf.org/html/draft-kucherawy-dmarc-base-04#section-15.4
 550 5.7.1 Email rejected per DMARC policy for example.com
It should make your internal discussion easier…

We found out that putting the word DMARC in the error message, allows bounce 
processors at ESPs, mailing lists, to understand there is a mailbox there, just 
not taking that email...

Cheers

On Jun 20, 2014, at 2:58 AM, John Mears john_me...@symantec.com wrote:

 Currently we give a generic SMTP error stating that we filtered the email, 
 without giving reasons, ie a fairly opaque message. Actually this is under 
 discussion internally. We need to strike a compromise between being 
 informative to legitimate senders while not revealing the internal workings 
 of our service to other senders.
 
 John
 
 -Original Message-
 From: Franck Martin [mailto:fmar...@linkedin.com] 
 Sent: 19 June 2014 17:53
 To: John Mears
 Cc: dmarc-discuss@dmarc.org
 Subject: Re: [dmarc-discuss] On Inbound DMARC Support
 
 
 On Jun 19, 2014, at 7:14 AM, John Mears via dmarc-discuss 
 dmarc-discuss@dmarc.org wrote:
 
 
 I believe there are some announcements expected shortly, and both Symantec 
 and Halon are already offering it as a cloud filtering service. (I think I'm 
 forgetting another service...)
 
 --Steve.
 
 Indeed, the Symantec hosted email security service now sports a check box 
 for enabling DMARC for inbound  emails. I wrote the code behind it. We are 
 seeing customers gradually enabling it.
 
 
 What is the SMTP error message when an email is rejected? I'm curious.
 



signature.asc
Description: Message signed with OpenPGP using GPGMail
___
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

[Franck Martin via dmarc-discuss]

On Jun 20, 2014, at 9:31 AM, Steve Atkins via dmarc-discuss 
dmarc-discuss@dmarc.org wrote:

 
 On Jun 20, 2014, at 8:45 AM, Brian Westnedge via dmarc-discuss 
 dmarc-discuss@dmarc.org wrote:
 
 Here's a simple use case for a spear-phisher where DMARC could be effective 
 on the inbound:
 
 1. Phisher targets a specific exec at bigbank.com
 2. Phisher sends fake FedEx tracking email from fedex.com (p=reject) to 
 exec's admin with a note from exec for admin to track a shipment that has 
 been ordered  
 3. Assuming DMARC is not being checked on the inbound, Admin clicks 
 malicious tracking number link, credentials are stolen, breach ensues 
 
 The above does of course assume that the phisher is either not familiar with 
 DMARC, or thinks that it won't be checked by a B2B entity like bigbank.com.
 
 Right. Any approach that's predicated on the assumption that someone behind a 
 spear-phishing (or other APT-esque) attack is stupid and/or unaware of 
 generally known anti-phishing approaches is probably flawed. As is any that 
 assumes that once the spear-phisher sends one email that bounces they're 
 going to just give up on that target and move on.
 
Your logic is flawed, because you imply that therefore DMARC is useless in 
fighting spear-phishing. The next conclusion, is that all anti-spam techniques 
are useless, because they don’t solve spam as a whole…

Spear phishing nowadays is not that targeted and are usually stupid and 
extremely effective. Once they are obliged to use a non DMARC protected domain, 
it becomes easier to spot.

DMARC is only a tool that close a specific hole, you need to close the other 
holes, so you can manually watch the few that are left...

Oh, and data has shown that they are indeed moving on to non DMARC protected 
domains...



signature.asc
Description: Message signed with OpenPGP using GPGMail
___
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

[Franck Martin via dmarc-discuss]

On Jun 19, 2014, at 7:14 AM, John Mears via dmarc-discuss 
dmarc-discuss@dmarc.org wrote:

 
 I believe there are some announcements expected shortly, and both Symantec 
 and Halon are already offering it as a cloud filtering service. (I think I'm 
 forgetting another service...)
 
 --Steve.
 
 Indeed, the Symantec hosted email security service now sports a check box for 
 enabling DMARC for inbound  emails. I wrote the code behind it. We are seeing 
 customers gradually enabling it.
 

What is the SMTP error message when an email is rejected? I'm curious.


___
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

[Franck Martin via dmarc-discuss]

On Jun 7, 2014, at 7:44 PM, Dave Crocker d...@dcrocker.net wrote:

 On 6/7/2014 7:31 PM, Franck Martin wrote:
 But the claim is that these workarounds will mainly happen after you do 
 DMARC p=reject. This data is coming in a not too distant future now.
 
 
 Keeping in mind that the mailing list scenario has always been
 legitimate use, the concern is that we may be left with a long-term
 barrier to that use, with no attendant long-term benefit.

It has always been clear with p=reject a domain cannot have email addresses 
subscribed to mailing lists and be able to interact with other list members 
successfully/adequately. Mailing lists needed to protect themselves, but I 
consider that as a different problem. Now it seems you can have a p=reject and 
participate successfully in some mailing lists (like this one).

 
 The fact that there is short-term benefit is not the issue; it is that
 the benefit might not sustain.
 
From the beginning the claim has always been to move the bad guys away from the 
real thing.

I think we have already envisioned the future, we don’t know which one will 
hold.

And as we say, this is our “Next Play”.



signature.asc
Description: Message signed with OpenPGP using GPGMail
___
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

[Franck Martin via dmarc-discuss]

On Jun 7, 2014, at 10:42 PM, Larry Finch via dmarc-discuss 
dmarc-discuss@dmarc.org wrote:

 
 On Jun 7, 2014, at 4:14 PM, Shal Farley s...@roadrunner.com wrote:
 
 Larry,
 
 Except, as I and others have discovered in the past few days, DMARC does 
 NOT make email so much more secure,” as phishers and spammers have 
 already found workarounds to continue their assault.
 
 It can't by itself, no. It needs to be used together with some means to 
 knock out the look-alike domains. Such as an address-book filter, or a 
 reputation-based filter. But that puts us back into the arguments about the 
 value of anything that relies on user behavior, including the need to patrol 
 a Spam folder for the inevitable false-positives.
 
 So all DMARC has accomplished is to inconvenience large, distributed 
 communities of legitimate mail forwarders such as mailing lists ...
 
 And the email users that rely on them.
 
 ... with no long term benefit.
 
 I'm not so pessimistic as to think that there will be no long term benefit. 
 I just can't imagine any way to effectively obtain that benefit without 
 involving the receiving MUA and its users.
 
 
 I agree with that. But I’ve been around this for almost 20 years, and there 
 have been many schemes to stop spam and phishing, from blocking open relays, 
 SPF, DKIM, hundreds of RBLs and DBLs, and now DMARC. But no matter what 
 defense gets erected the miscreants find ways around it. And each one takes a 
 toll on legitimate users. This is essentially an arms race, and the bad guys 
 are winning.  What is really needed is more savvy end users. It has been 
 jokingly suggested that perhaps you should need a user’s license and have to 
 pass tests before being allowed to use the Internet. Obviously not practical, 
 but anything else is unlikely to work.
 
May be postmasters should have a license, which would require them to set up 
SPF, DKIM, DMARC, rDNS, and other things correctly… wait….



signature.asc
Description: Message signed with OpenPGP using GPGMail
___
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?

[Franck Martin via dmarc-discuss]

On Jun 5, 2014, at 5:34 PM, Terry Zink via dmarc-discuss 
dmarc-discuss@dmarc.orgmailto:dmarc-discuss@dmarc.org wrote:

Franck,

 See the end of the email, where I argued this case… and It is hard to create
 a club and define the entry level which is open to all, provided they meet
 some requirements.

Yes, it is difficult and I think it’s one of the biggest barriers to getting a 
common solution for trusted senders. I don’t think that your solution of 
authentication-only is enough, as I explain below.

 Besides whoever registered 1inkedin.comhttp://1inkedin.com/ and use it to 
 misrepresent us, may have
 to deal with our lawyers… and I’m not a lawyer… and that would be after
 spamhaus and/or surbl certainly list this domain...

Whether or not they deal with your lawyers is beside the point. If the only 
criteria for highlighting with a green bar is authentication, then not only can 
phishers do this by impersonating trusted brands, but so can run-of-the-mill 
spammers. In Office 365, we are dealing with a spammer who every day registers 
dozens of new domains and sets up SPF. It would be trivial for him to set up 
DKIM and DMARC. It’s true that SURBL or Spamhaus may list his domains but it 
doesn’t matter from his perspective because he abandons it after he has made 
his money with it anyhow.

Not only that, but we would then have the worst of both worlds. Users see a 
green bar for both trusted domains *and* spamming domains. We are training 
users that the green bar means… what, exactly? They’re supposed to trust the 
green bar but this is not possible if senders can self-validate.


Hmm... Anyone can have a SSL certificate on any domain, sometimes, even on a 
domain they don't own... Yes it should be authentication only. The user can 
read the domain name, and see if it correspond to something he/she knows.

As for your current case, there are a few techniques to alleviate this problem, 
one which is to rate limit any new account till you have built a reputation.

We all suffer from mass creation of bad accounts, there are techniques to find 
out who register what and limit it.


___
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?

[Franck Martin via dmarc-discuss]

On Jun 5, 2014, at 11:54 AM, Mason Schmitt via dmarc-discuss 
dmarc-discuss@dmarc.org wrote:

 
 On Jun 5, 2014, at 9:26 PM, Al Iverson via dmarc-discuss 
 dmarc-discuss@dmarc.org wrote:
 
 And also, do recognize that DMARC is only one part of the badness
 prevention equation, it doesn't cover ever single eventuality. It
 locks one door, not all doors, no? I'd be curious about that left off
 the domain one; if an ISP were already rejecting mail from domains
 that don't resolve, I doubt it would have been delivered.
 
 When I was managing a mail server, 3 years ago, I saw many phishing emails 
 where the display name was designed to fool our customers into thinking the 
 email was from us.  The email address part of the From: was from valid 
 domains that would often pass SPF and various other checks and would thus not 
 be rejected by our system based on domain validity. We did however create 
 custom heiristics to catch these emails and hold them for review, so they 
 weren't delivered to our customers, but this was of course not a general 
 solution to the problem. 
 
 As has been pointed out in this thread, this issue is not something DMARC was 
 designed to solve and is really an MUA issue. However, if we look at these 
 sorts of emails, from the user's point of view, the fact the MUA makes it 
 appear the email is from a known aol sender, is just as bad as if the phish 
 were done using the full aol.com domain.
 
 I didn't have a general purpose solution to the problem 3 years ago and I 
 still can't think of one that doesn't involve the MUAs changing their 
 behavior. 
 

So I raised a point on dm...@ietf.org with the problem of spam filtering based 
on content, vs identifiers.

Bayesian type of spam filtering looks at the content and select meaningful 
words to classify the content, however it may not choose the domain in the 
From: therefore at long as the email looks like the same as something known, 
then it is classified as good.

If we can tweak the classifier to indicate the domain in the From is very 
important, and that a type of email usually associated with a domain, when seen 
but from a different domain would be considered as more suspicious.




signature.asc
Description: Message signed with OpenPGP using GPGMail
___
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?

[Franck Martin via dmarc-discuss]

On Jun 5, 2014, at 4:06 PM, Murray S. Kucherawy via dmarc-discuss 
dmarc-discuss@dmarc.org wrote:

 On Thu, Jun 5, 2014 at 1:49 PM, Les Barstow via dmarc-discuss 
 dmarc-discuss@dmarc.org wrote:
 I agree - DMARC does not protect against the From description. But if the MUA 
 were to display the full From header rather than the description only, we 
 might be getting somewhere.
 
 The rest of your response backs up my point; the will to get this done 
 right in a broader sense does not exist and we're left with ineffective 
 band-aids and holes large enough to drive a truck full of phish through.
 
 +1.  Any comprehensive solution to this cluster of problems requires that the 
 discussion cover everything from the IP layer all the way up through layer 9, 
 and not punt on any of it.  That obviously exceeds the scope of anything 
 we've tried before, but that doesn't change this ultimate requirement.
 

As pointed to me, this could be a Wicked Problem: 
http://en.wikipedia.org/wiki/Wicked_problem and be approached as such which is 
not the type of problem engineers may handle well.



signature.asc
Description: Message signed with OpenPGP using GPGMail
___
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?

[Franck Martin via dmarc-discuss]

On Jun 5, 2014, at 4:22 PM, Terry Zink via dmarc-discuss 
dmarc-discuss@dmarc.org wrote:

 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.
  
 -- Terry
  
You could just show the domain in green on the MUA, to show that this email is 
successfully DMARC authenticated by the domain and the domain as strong DMARC 
policies (p=reject). I feel it should show the UTF8 version as well as the puny 
code version….

No need of a CA.

Spammers could use DMARC too, but it is about authentication/attribution not 
about reputation.

It seems to me the DMARC spec, should contain strong advice to MUA. MUA 
developers do read RFCs, otherwise they would never have done POP/IMAP...



signature.asc
Description: Message signed with OpenPGP using GPGMail
___
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 IP failing SPF?

[Franck Martin via dmarc-discuss]

The policy_evaluated part indicates the DKIM+alignement and SPF+alignment 
result, not the core DKIM and SPF test, which is later in the record see 
http://www.dmarc.org/faq.html#r_3

On May 30, 2014, at 4:29 PM, Tomasz Chmielewski via dmarc-discuss 
dmarc-discuss@dmarc.org wrote:

 178.63.195.102 is allowed in SPF:
 
 # dig +short TXT ptraveler.com
 v=spf1 a mx ip4:178.63.195.102 ip6:2a01:4f8:120:22eb:: ip4:46.4.130.2 
 ~all
 spf2.0/pra a mx ip4:178.63.195.102 ip6:2a01:4f8:120:22eb:: 
 ip4:46.4.130.2 ~all
 
 
 And yet, hotmail sends:
 
 row
 source_ip178.63.195.102/source_ip
 count1/count
 policy_evaluated
 dispositionnone/disposition
 dkimfail/dkim
 spffail/spf
 /policy_evaluated
 /row
 



signature.asc
Description: Message signed with OpenPGP using GPGMail
___
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 Successful Mail Delivery Reports

[Franck Martin via dmarc-discuss]

Besides the backscatter AOL is creating and should stop, seems you should move 
your domain to p=reject to avoid that these spoofed emails get delivered to aol 
users and others...

Printed on recycled paper!

 On May 11, 2014, at 19:34, Scott Kitterman via dmarc-discuss 
 dmarc-discuss@dmarc.org wrote:
 
 Over the last few days I've gotten a number of bounces like this, all from 
 AOL:
 
 Return-Path: 
 Received: from imb-d04.mx.aol.com (imb-d04.mx.aol.com [205.188.128.65])
by qs3710.pair.com (Postfix) with ESMTPS id 51A76125427
for i...@kitterman.com; Sun, 11 May 2014 13:05:39 -0400 (EDT)
 Received: from mtaig-mca02.mx.aol.com (mtaig-mca02.mx.aol.com [172.26.221.66])
(using TLSv1 with cipher ADH-AES256-SHA (256/256 bits))
(No client certificate requested)
by imb-d04.mx.aol.com (AOL Mail Bouncer) with ESMTPS id 12B0E38000AA
for i...@kitterman.com; Sun, 11 May 2014 13:05:39 -0400 (EDT)
 Received: by mtaig-mca02.mx.aol.com (Internet Inbound)
id 040077087; Sun, 11 May 2014 13:05:39 -0400 (EDT)
 Date: Sun, 11 May 2014 13:05:39 -0400 (EDT)
 From: mailer-dae...@aol.com (Mail Delivery System)
 Subject: Successful Mail Delivery Report
 To: i...@kitterman.com
 Auto-Submitted: auto-replied
 MIME-Version: 1.0
 Content-Type: multipart/report; report-type=delivery-status;
boundary=8C3437094.1399827939/mtaig-mca02.mx.aol.com
 Message-Id: 20140511170539.040077...@mtaig-mca02.mx.aol.com
 
 This is a MIME-encapsulated message.
 
 --8C3437094.1399827939/mtaig-mca02.mx.aol.com
 Content-Description: Notification
 Content-Type: text/plain; charset=us-ascii
 
 Your message was successfully delivered to the destination(s)
 listed below. If the message was delivered to mailbox you will
 receive no further notifications. Otherwise you may still receive
 notifications of mail delivery errors from other systems.
 
 Please direct further questions regarding this message to your e-mail
 administrator.
 
 --AOL Postmaster
 
 
 erica.bbr...@aim.com: alias expanded
 
 --8C3437094.1399827939/mtaig-mca02.mx.aol.com
 Content-Description: Delivery report
 Content-Type: message/delivery-status
 
 Reporting-MTA: dns; mtaig-mca02.mx.aol.com
 X-Internet-Inbound-Queue-ID: 8C3437094
 X-Internet-Inbound-Sender: rfc822; i...@kitterman.com
 Arrival-Date: Sun, 11 May 2014 13:05:38 -0400 (EDT)
 
 Final-Recipient: rfc822; erica.bbr...@aim.com
 Original-Recipient: rfc822;erica.bbr...@aim.com
 Action: expanded
 Status: 2.0.0
 Diagnostic-Code: X-Internet-Inbound; alias expanded
 
 --8C3437094.1399827939/mtaig-mca02.mx.aol.com
 Content-Description: Message Headers
 Content-Type: text/rfc822-headers
 
 Return-Path: i...@kitterman.com
 Received: from are-financed-errors.oilbrooklyn.com (safety-good-
 sparkprovo.oilbrooklyn.com [199.175.55.32])
by mtaig-mca02.mx.aol.com (Internet Inbound) with ESMTP id 8C3437094
for erica.bbr...@aim.com; Sun, 11 May 2014 13:05:38 -0400 (EDT)
 Date: Sun, 11 May 2014 06:30:50 CDT
 Mime-Version: 1.0
 X-MSGID:1
 Content-Type: text/html
 From:  Loan Department. i...@kitterman.com
 To: erica.bbr...@aim.com
 Subject:  RE:Congratulations erica.bbrown $9500 Available For You!
 x-aol-global-disposition: S
 X-AOL-SCOLL-DMARC: mtaig-mca02.mx.aol.com ; domain : kitterman.com ; policy : 
 none ; result : F
 Authentication-Results: mx.aol.com;
spf=fail (aol.com: the domain kitterman.com reports that 199.175.55.32 is 
 explicitly not authorized to send mail using it's domain name.) 
 smtp.mailfrom=kitterman.com;
dmarc=fail (aol.com: the domain kitterman.com reports that Neither SPF nor 
 DKIM align.) header.from=kitterman.com;
 X-AOL-REROUTE: YES
 x-aol-sid: 3039ac1add42536fade22f5e
 X-AOL-IP: 199.175.55.32
 X-AOL-SPF: domain : kitterman.com SPF : fail
 
 --8C3437094.1399827939/mtaig-mca02.mx.aol.com--
 
 Dear AOL: please stop.  This is brain dead.  In case anyone is wondering, no 
 one from i...@kitterman.com sent erica.bbrown any mail telling here we had 
 $9500 available for her.
 
 I don't know for sure if this is related to DMARC or not, but the timing 
 seems 
 to be roughly in line with their rollout of DMARC p=reject.
 
 I have more if anyone wants to see them.
 
 Scott K
 ___
 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] DMARC Successful Mail Delivery Reports

[Franck Martin via dmarc-discuss]

Not exactly, the failure reports are not supposed to go back to the (fake) 
sender but to the email specific by the ruf. This seems a delivery 
notification, so besides a bug at AOL, I would think that the fake email 
contains a delivery receipt header... Which AOL would honor...

I did not see such read receipt header in the original email, but it could have 
been removed as part of the notification.

Printed on recycled paper!

 On May 11, 2014, at 20:15, Roland Turner via dmarc-discuss 
 dmarc-discuss@dmarc.org wrote:
 
 You have p=none and ruf= turned on, AOL's doing exactly what you've requested.
 
 - Roland
 
 
 On 05/12/2014 10:25 AM, Scott Kitterman via dmarc-discuss wrote:
 Over the last few days I've gotten a number of bounces like this, all from
 AOL:
 
 Return-Path: 
 Received: from imb-d04.mx.aol.com (imb-d04.mx.aol.com [205.188.128.65])
by qs3710.pair.com (Postfix) with ESMTPS id 51A76125427
for i...@kitterman.com; Sun, 11 May 2014 13:05:39 -0400 (EDT)
 Received: from mtaig-mca02.mx.aol.com (mtaig-mca02.mx.aol.com 
 [172.26.221.66])
(using TLSv1 with cipher ADH-AES256-SHA (256/256 bits))
(No client certificate requested)
by imb-d04.mx.aol.com (AOL Mail Bouncer) with ESMTPS id 12B0E38000AA
for i...@kitterman.com; Sun, 11 May 2014 13:05:39 -0400 (EDT)
 Received: by mtaig-mca02.mx.aol.com (Internet Inbound)
id 040077087; Sun, 11 May 2014 13:05:39 -0400 (EDT)
 Date: Sun, 11 May 2014 13:05:39 -0400 (EDT)
 From: mailer-dae...@aol.com (Mail Delivery System)
 Subject: Successful Mail Delivery Report
 To: i...@kitterman.com
 Auto-Submitted: auto-replied
 MIME-Version: 1.0
 Content-Type: multipart/report; report-type=delivery-status;
boundary=8C3437094.1399827939/mtaig-mca02.mx.aol.com
 Message-Id: 20140511170539.040077...@mtaig-mca02.mx.aol.com
 
 This is a MIME-encapsulated message.
 
 --8C3437094.1399827939/mtaig-mca02.mx.aol.com
 Content-Description: Notification
 Content-Type: text/plain; charset=us-ascii
 
 Your message was successfully delivered to the destination(s)
 listed below. If the message was delivered to mailbox you will
 receive no further notifications. Otherwise you may still receive
 notifications of mail delivery errors from other systems.
 
 Please direct further questions regarding this message to your e-mail
 administrator.
 
 --AOL Postmaster
 
 
 erica.bbr...@aim.com: alias expanded
 
 --8C3437094.1399827939/mtaig-mca02.mx.aol.com
 Content-Description: Delivery report
 Content-Type: message/delivery-status
 
 Reporting-MTA: dns; mtaig-mca02.mx.aol.com
 X-Internet-Inbound-Queue-ID: 8C3437094
 X-Internet-Inbound-Sender: rfc822; i...@kitterman.com
 Arrival-Date: Sun, 11 May 2014 13:05:38 -0400 (EDT)
 
 Final-Recipient: rfc822; erica.bbr...@aim.com
 Original-Recipient: rfc822;erica.bbr...@aim.com
 Action: expanded
 Status: 2.0.0
 Diagnostic-Code: X-Internet-Inbound; alias expanded
 
 --8C3437094.1399827939/mtaig-mca02.mx.aol.com
 Content-Description: Message Headers
 Content-Type: text/rfc822-headers
 
 Return-Path: i...@kitterman.com
 Received: from are-financed-errors.oilbrooklyn.com (safety-good-
 sparkprovo.oilbrooklyn.com [199.175.55.32])
by mtaig-mca02.mx.aol.com (Internet Inbound) with ESMTP id 8C3437094
for erica.bbr...@aim.com; Sun, 11 May 2014 13:05:38 -0400 (EDT)
 Date: Sun, 11 May 2014 06:30:50 CDT
 Mime-Version: 1.0
 X-MSGID:1
 Content-Type: text/html
 From:  Loan Department. i...@kitterman.com
 To: erica.bbr...@aim.com
 Subject:  RE:Congratulations erica.bbrown $9500 Available For You!
 x-aol-global-disposition: S
 X-AOL-SCOLL-DMARC: mtaig-mca02.mx.aol.com ; domain : kitterman.com ; policy :
 none ; result : F
 Authentication-Results: mx.aol.com;
spf=fail (aol.com: the domain kitterman.com reports that 199.175.55.32 is
 explicitly not authorized to send mail using it's domain name.)
 smtp.mailfrom=kitterman.com;
dmarc=fail (aol.com: the domain kitterman.com reports that Neither SPF nor
 DKIM align.) header.from=kitterman.com;
 X-AOL-REROUTE: YES
 x-aol-sid: 3039ac1add42536fade22f5e
 X-AOL-IP: 199.175.55.32
 X-AOL-SPF: domain : kitterman.com SPF : fail
 
 --8C3437094.1399827939/mtaig-mca02.mx.aol.com--
 
 Dear AOL: please stop.  This is brain dead.  In case anyone is wondering, no
 one from i...@kitterman.com sent erica.bbrown any mail telling here we had
 $9500 available for her.
 
 I don't know for sure if this is related to DMARC or not, but the timing 
 seems
 to be roughly in line with their rollout of DMARC p=reject.
 
 I have more if anyone wants to see them.
 
 Scott K
 ___
 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)
 
 
 -- 
  Roland Turner | Director, Labs
  TrustSphere Pte Ltd | 3 Phillip Street #13-03, Singapore 048693
  Mobile: +65 96700022 | Skype: 

Re: [dmarc-discuss] DMARC woes - forwarding signed / encrypted e-mail

[Franck Martin via dmarc-discuss]

On May 9, 2014, at 2:42 PM, Michael Adkins via dmarc-discuss 
dmarc-discuss@dmarc.org wrote:

 
 
 On 5/9/14, 2:20 PM, J. Gomez jgo...@seryrich.com wrote:
 
 It is clear YAHOO and AOL have watered down the value, meaning and
 trustworthiness of p=reject
 
 Yes, I understand that that is your opinion.  I have yet to see any
 evidence of actual system changes to support it.  I haven¹t had to make
 any changes to mine, but I recognize that a system on a scale of millions
 of active users doesn¹t have the same challenges as one with hundreds of
 millions of active users.  I am asking for the people who actually run
 those systems to share what they have actually done, not for people who
 don¹t to speculate about it.
 

I did not change anything either on our DMARC implementation, pre and post 
yahoo. Our DMARC implementation is public by the way.



signature.asc
Description: Message signed with OpenPGP using GPGMail
___
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] About that From: field

[Franck Martin via dmarc-discuss]

On May 10, 2014, at 2:29 AM, John Levine via dmarc-discuss 
dmarc-discuss@dmarc.org wrote:

 Oh, wow.  The mail going into the archive isn't the same as the mail
 going out to the list.  I wonder what we'll fix next.
 
 This feels like complaining for complaining's sake. Do you prefer that
 the from address in the archive be similarly modified, or do you prefer
 to limit the modification to only exactly when necessary?
 
 I prefer that the archive be an archive of the actual list.  That
 doesn't seem particularly exotic.
 
Please open a bug with mailman, they did not feel it the same way as you...



signature.asc
Description: Message signed with OpenPGP using GPGMail
___
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 woes - forwarding signed / encrypted e-mail

[Franck Martin via dmarc-discuss]

On May 8, 2014, at 8:03 PM, Murray S. Kucherawy via dmarc-discuss 
dmarc-discuss@dmarc.org wrote:

 On Thu, May 8, 2014 at 12:28 PM, J. Gomez jgo...@seryrich.com wrote:
  It seems to me that a particularly defensive receiver would run the
  heuristic/whitelist checks on all messages anyway.
 
 Why? It seems to me that a particularly defensive receiver would instantly 
 drop dead incoming email which fails a DMARC check and comes from a domain 
 with p=reject;l=no, without subjecting it to any further processing 
 whatsoever.
 
 Because they're local and/or cheap (they don't exactly require an AI or ML 
 engine), and it's best for the final accept/reject/spam-folder decision to be 
 made with as much data as possible.
 
 Perhaps you're assuming that those checks are expensive?  I would bet that 
 even for medium-sized operators, they are not; the heuristics amount to a 
 relatively small number of header field retrieve and analyze operations 
 (string comparisons, hash table lookups, etc.), and the whitelist check would 
 be a local database query with a Boolean result.  The high cost would occur 
 for operators with very low compute power or network latency such that those 
 checks are costly, but that would also disqualify them from things like DNSBL 
 queries that are typically done on every message.
 
 For large operators that have tons of data, they can have dedicated processes 
 that look through message histories to find out behavior patterns indicative 
 of lists, and update their own internal whitelists.  The query to the 
 whitelist upon message receipt is cheap because it's local; it's the analysis 
 that's expensive, but it's likely not done as part of the message receipt 
 pipeline.
 
 For small operators without such resources, they would import or query an 
 external whitelist, or the heuristic would amount to something akin to a 
 Spamassassin rule that, again, is just some string comparison operations, 
 updates to which are periodically updated, possibly automatically.
 
You could also log the IP of an email that fail DMARC but contains a List-Id or 
List-post header, and then every day review this log and add the relevant IPs 
in an DMARC-MLM override whitelist. A user subscribing to a mailing list, would 
loose just a few emails till the whitelist kicks in….



signature.asc
Description: Message signed with OpenPGP using GPGMail
___
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)