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

[Brandon Long via dmarc-discuss]

On Wed, May 19, 2021 at 1:08 PM John Levine via dmarc-discuss <
dmarc-discuss@dmarc.org> wrote:

> It appears that Alexander NAZARIAN via dmarc-discuss <
> alexander.nazar...@gmail.com> said:
> >So I want to understand whether having MX placed in the beginning of SPF
> >record can cause a quicker reach of '10 DNS lookup limitation' for G Suite
> >senders, due to the reason that G Suite has 5 MX records (and I assume
> that
> >number of DNS queries, executed to resolve MXes to IPs, is 6 and not 1)
>
> I think he already answered that question. Different implementations
> of SPF interpret the counting rule differently, so if you want your
> mail delivered, assume that they will use the largest count. If you
> are checking else's mail, use the smallest count. This is the well
> known robustness principle about interpreting ambiguous specs.
>
> This particular case has not come up in the past because, in practice,
> the only sites that use "mx" are tiny sites with a single mail host
> with a single address. It doesn't make a lot of sense for secondary MX
> hosts to be sending mail for someone's domain.
>
> I also think that some of the advice about limits in 7208 is not very
> good.  For example.
> you are likely to get different NOERROR counts evalating an ipv4 address
> than evaluating
> an ipv6 addresss since there are lots of hosts with A records but no .
>

I think the limits in the RFC are overly restrictive... as a receiver, I
don't see any issue with having a
much higher limit, you waste fairly minimal resources in that regard...
there may be an issue in the large
as a DoS type attack, but as a larger provider you might benefit more from
weighted throttling of requests
or more general DoS-style protections.

At least at one point we definitely saw enough senders requiring too many
lookups that we cared more about
trying to find a positive evaluation than downside from doing more.

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

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

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

[Brandon Long via dmarc-discuss]

On Mon, Aug 31, 2020 at 11:23 AM John Levine via dmarc-discuss <
dmarc-discuss@dmarc.org> wrote:

> In article  aoy9o3mw4-uoyo9dh_c3ulpmwnb...@mail.gmail.com> you write:
> >-=-=-=-=-=-
> >-=-=-=-=-=-
> >
> >With some of my recent DMARC reports for my domains I've seen comments
> >about over riding the p=reject and deciding the mail should be quarantined
> >vs rejected because the recipient mailbox provider thought it was
> >forwarded.
> >
> >Would it be useful to add an additional DMARC be expanded to have a
> >'p=nomail' value so when a domain that is already publishing "v=spf1 -all"
> >and has a 'p=reject' value that it really should be rejected regardless of
> >what the recipient domain thinks about a mail being forwarded or not?
>
> We already have SPF "v=spf1 -all" to say that a domain sends no mail,
> and MX 0 . to say that it receives no mail. In general it's not a
> great idea to invent multiple ways to say the same thing, or to look
> at it another way, if recipients aren't taking the hint from SPF, why
> do we think they'd pay attention to a similar hint from DMARC?
>

Hmm, DMARC is for the header from domain, however, I wonder if folks
usually only do the spf lookup
on the mail from argument, which may not be aligned and therefore doesn't
hit that.

Not that an inbound filter couldn't also do an spf lookup on the header
from domain... or an mx lookup
on the reply to domain for that matter.

And then how would this also play with say the Sender: header override
draft, would you expect to
listen to the SPF for the header from domain saying "no mail" or allow
override?

Agreed with the general case of "I really mean it" though.

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

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

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

[Brandon Long via dmarc-discuss]

We still see some rate limiting rejections on our RUA address, though a
very low percentage.  Seems most sites generate their reports on likely
"midnight" boundaries, so the result is definitely similar to a very sharp
but not long lasting DDOS.  It's large enough that it skips right to the
perm reject for some of the excess.  Completely whitelisting anything is
never wise, at the least these things do compete with the regular email
load that one might consider more important than these reports.  Increasing
the allowed rate has been done multiple times, but apparently it's
exceeding the last attempt yet again.

And honestly, I never expected anyone would care about the bounces or would
really pay attention to them.  A small fraction of reports missing is
unlikely to change the information we derive from them, especially as the
"who" we bounce probably changes from day to day.

Brandon

On Thu, Apr 16, 2020 at 3:07 PM Jonathan Kamens via dmarc-discuss <
dmarc-discuss@dmarc.org> wrote:

> On 4/15/20 3:48 PM, John Levine wrote:
>
> In article <65960f35-16b5-7889-5db1-c5c678015...@kamens.us> 
> <65960f35-16b5-7889-5db1-c5c678015...@kamens.us> you write:
>
> For your edification, below, in domain rank order (from 
> thehttps://domcop.com/openpagerank/ API), are the ranked domains that have
> bounced at least one DMARC aggregate report my mail server has tried to
> send them since I started tracking this in September 2018.
>
> There are a lot of domains on this list that are big enough that they
> really should be able to handle something as critical as not bouncing
> aggregate reports sent to the email address they advertise for them.
>
> One rejected report in about 500 days is an 0.2% bounce rate.  That seems
> a bit extreme.
>
> I said *at least* one, not *exactly *one. Once a site bounces a report I
> add them to an exclude list and stop trying to send them reports, so I
> don't actually know how many bounces any of these domains generated. I
> doubt it's just one.
>
> Do you have an idea of why they're being rejected?  Yahoo in
> particular sometimes has bad days (I think due to DDoS) and defers or
> fails to accept mail to anyone.  It's nothing personal.
>
> Reports whose delivery were deferred don't show up on my list; it's just
> for reports that were permanently bounced. And personally, I don't care why
> they bounced. Rejecting the reports means more work for the servers sending
> them and the people who maintain those servers, assuming that those people
> are trying to do the right thing as opposed to just black-holing bounces.
> If a site doesn't want to process the reports for whatever reason then they
> should accept them and throw them away, not bounce them. In my opinion It's
> a bad look for domains that can't manage even that reliably.
>
> When I first started maintaining the list of domains not to generate
> reports for, I did keep track of why they were bouncing, though I don't do
> that anymore. Here are some of the bounce causes I saw (not a comprehensive
> list, obviously):
>
> youtube.com: rate limiting on the RUA mailbox
> google.com: rate limiting on the RUA mailbox
> flattr.com: message content rejected
> trendmicro.com: connection timed out (for several days)
> pobox.com: DMARCIFY appears to be out of commission; Pobox has since
> switched to fastmaildmarc.com
>
>   jik
> ___
> 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] PolicyPublished, was PolicyOverride in Reporting

[Brandon Long via dmarc-discuss]

00f.org        |
> >> |   44200 |1 | freecycle.org   |
> >> |   84600 |2 | resoundnetworks.com |
> >> |   86400 | 1085 | 06d01.mspz3.gob.ec  |
> >> |  342000 |1 | fmp.com |
> >> |  604800 |3 | cgates.lt   |
> >> +-+--+-+
> >> 17 rows in set (0.11 sec)
> >>
> >>
> >> [†] zaggregate is the name of my reporting program.
> >> http://www.tana.it/sw/zdkimfilter/zaggregate.html
> >>
> >> [‡] http://bit.ly/dmarc-rpt-schema
> >>
> >>
> >>
> >> On Wed 29/Jan/2020 12:18:20 +0100 Dotzero via dmarc-discuss wrote:
> >>> +1 to what Brandon wrote.
> >>>
> >>> On Tue, Jan 28, 2020 at 8:23 PM Brandon Long via dmarc-discuss <
> >>> dmarc-discuss@dmarc.org> wrote:
> >>>
> >>>> Isn't the override in the RowType?  So you can just have multiple
> >>>> RecordTypes, each with different RowTypes?
> >>>>
> >>>> Ultimately, it seems like the report is a bunch of fields with a
> count,
> >>>> and so the composition is to make sure that the set of rows is a
> "unique"
> >>>> key.  Theoretically you should log even the published policy at eval
> time,
> >>>> so you can report different counts even if the policy changes over
> that
> >>>> period... even if you'd have to send separate reports.
> >>>>
> >>>> The schema doesn't really make that clear, to my mind, I wouldn't have
> >>>> buried the count.
> >>>>
> >>>> Brandon
> >>>>
> >>>> On Tue, Jan 28, 2020 at 5:26 AM Brotman, Alex via dmarc-discuss <
> >>>> dmarc-discuss@dmarc.org> wrote:
> >>>>
> >>>>> What is to be done if only a portion of the messages from the
> reporting
> >>>>> period receive a policy override?  Perhaps this is done based on IP,
> or
> >>>>> only applied part way through the day.  It seems like in the
> specification,
> >>>>> the reporting definition assumes the entire set of reported messages
> has
> >>>>> the override.
> >>>>>
> >>>>> --
> >>>>> Alex Brotman
> >>>>> Sr. Engineer, Anti-Abuse & Messaging Policy
> >>>>> Comcast
> >>>>>
> >>>>>
> >>>>> ___
> >>>>> 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)
> >
>
___
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] PolicyPublished, was PolicyOverride in Reporting

[Brandon Long via dmarc-discuss]

I mean, we're google, so our reporting is done via map reduce (well,
probably a flume now), and so we just build up a list of unique key
counters and then group those by the things that are unique by email.  We
already generate multiple reports to address because of size constraints.

Brandon

On Fri, Jan 31, 2020 at 4:38 AM Alessandro Vesely via dmarc-discuss <
dmarc-discuss@dmarc.org> wrote:

> Hi,
>
> I'm not clear on what Brandon actually said.  I agree that the schema
> doesn't
> make that clear:
>
> policy_published, like report_metadata, occurs once in a report.  I don't
> think
> one should send multiple reports in the face of policy changes.  It would
> complicate report sending quite.
>
> Complication stems from the reporting period.  In practice, I have a cron
> job
> which runs after midnight UCT.  Hence, I apologize with those who have ri
> !=
> 86400[*], but I override the original ri and send reports daily.  If some
> day
> I'll notice daily is not enough, for example because I often would exceed
> the
> size limit, I may decide to run "zaggregate"[†] more often.  The spec says:
>
>   DMARC implementations
>   MUST be able to provide daily reports and SHOULD be able to
>   provide hourly reports when requested.
>
> Now, DMARC policy is looked up when mail is received.  In some cases, it is
> looked up again when the aggregate report is composed.  So, the reported
> policy_published is the one which was retrieved last.  Normally it is the
> one
> applied last (except in some cases...)
>
> I don't think that sending multiple records (to possibly different rua's)
> in an
> attempt to track policy changes is worth the complication.  Section 10.2,
> DNS
> Load and Caching, doesn't specify a TTL.  In fact, policies don't change so
> often.  Splitting reports on the odd day would disrupt both generators and
> consumers to no avail.
>
> For PolicyOverride, I fully agree it is part of the key, along with
> IPAddress.
>  I added a  to the example record at the bottom of Freddie's page[‡]
>
>
> Best
> Ale
> --
>
> [*] Most domain have an "original_ri" of 0, i.e. not specified.
> An excerpt from my tiny MTA's db:
>
> MariaDB [mail]> select original_ri, count(*), MIN(domain) from domain
> group by
> original_ri;
> +-+--+-+
> | original_ri | count(*) | MIN(domain) |
> +-+--+-+
> |   0 |   102730 | "BancaMarche"   |
> |   8 |1 | zaspy.com   |
> | 300 |2 | fcotten.nl  |
> | 600 |1 | 0086.info   |
> | 900 |1 | shopeemobile.com|
> |3600 |   79 | acbc.wa.edu.au  |
> |6400 |2 | ml.mkccvo.info  |
> |7200 |1 | anandbus.net|
> |8200 |1 | 123-reg.co.uk   |
> |   14400 |   15 | a1mailserver.com|
> |   21600 |4 | iijmio-mail.jp  |
> |   43200 |1 | f00f.org|
> |   44200 |1 | freecycle.org   |
> |   84600 |2 | resoundnetworks.com |
> |   86400 | 1085 | 06d01.mspz3.gob.ec  |
> |  342000 |1 | fmp.com |
> |  604800 |3 | cgates.lt   |
> +-+--+-+
> 17 rows in set (0.11 sec)
>
>
> [†] zaggregate is the name of my reporting program.
> http://www.tana.it/sw/zdkimfilter/zaggregate.html
>
> [‡] http://bit.ly/dmarc-rpt-schema
>
>
>
> On Wed 29/Jan/2020 12:18:20 +0100 Dotzero via dmarc-discuss wrote:
> > +1 to what Brandon wrote.
> >
> > On Tue, Jan 28, 2020 at 8:23 PM Brandon Long via dmarc-discuss <
> > dmarc-discuss@dmarc.org> wrote:
> >
> >> Isn't the override in the RowType?  So you can just have multiple
> >> RecordTypes, each with different RowTypes?
> >>
> >> Ultimately, it seems like the report is a bunch of fields with a count,
> >> and so the composition is to make sure that the set of rows is a
> "unique"
> >> key.  Theoretically you should log even the published policy at eval
> time,
> >> so you can report different counts even if the policy changes over that
> >> period... even if you'd have to send separate reports.
> >>
> >> The schema doesn't really make that clear, to my mind, I wouldn't have
> >> buried the count.
> >>
> >> Brandon
> >>
> >> On Tue, Jan 28, 2020 at 5:26 AM Brotman, Alex via dmarc-discus

Re: [dmarc-discuss] PolicyOverride in Reporting

[Brandon Long via dmarc-discuss]

Isn't the override in the RowType?  So you can just have multiple
RecordTypes, each with different RowTypes?

Ultimately, it seems like the report is a bunch of fields with a count, and
so the composition is to make sure that the set of rows is a "unique" key.
Theoretically you should log even the published policy at eval time, so you
can report different counts even if the policy changes over that period...
even if you'd have to send separate reports.

The schema doesn't really make that clear, to my mind, I wouldn't have
buried the count.

Brandon

On Tue, Jan 28, 2020 at 5:26 AM Brotman, Alex via dmarc-discuss <
dmarc-discuss@dmarc.org> wrote:

> What is to be done if only a portion of the messages from the reporting
> period receive a policy override?  Perhaps this is done based on IP, or
> only applied part way through the day.  It seems like in the specification,
> the reporting definition assumes the entire set of reported messages has
> the override.
>
> --
> Alex Brotman
> Sr. Engineer, Anti-Abuse & Messaging Policy
> Comcast
>
>
> ___
> 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] Fwd: Re: Help

[Brandon Long via dmarc-discuss]

On Wed, Sep 26, 2018 at 2:22 PM Lawrence Finch via dmarc-discuss <
dmarc-discuss@dmarc.org> wrote:

>
>
> On Sep 26, 2018, at 5:11 PM, Brandon Long  wrote:
>
> Wait, folks are on this list who don't know the basics?
>
> Ie:
> List-Unsubscribe: ,
> 
>
> on every message?
>
> Also, the link in the footer,
> http://www.dmarc.org/mailman/listinfo/dmarc-discuss, has a section that
> is the same on all mailman lists:
> To unsubscribe from dmarc-discuss, get a password reminder, or change your
> subscription options enter your subscription email address:
>
> So.. yeah.
>
> Brandon
>
>
> Yes, there are folks who don’t know. I am an administrator for 17 mailing
> lists using different technologies, and I belong to several more. Mailman
> is different from Yahoo Groups is different from Google Groups is different
> from L-Soft’s listserv (where most of my lists are). And every one has
> different subscribe and unsubscribe options. And every one of my lists has
> a link to unsubscribe in the footer. Just as this list should and is
> required by law, at least in the US. This is the only list I have
> encountered that does not follow this practice.
>

Citation needed.  CAN-SPAM refers to only commercial mail, which this list
is certainly not.  And the link in the footer does provide unsubscribe
instructions.

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

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

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

[Brandon Long via dmarc-discuss]

Wait, folks are on this list who don't know the basics?

Ie:
List-Unsubscribe: , 

on every message?

Also, the link in the footer,
http://www.dmarc.org/mailman/listinfo/dmarc-discuss, has a section that is
the same on all mailman lists:
To unsubscribe from dmarc-discuss, get a password reminder, or change your
subscription options enter your subscription email address:

So.. yeah.

Brandon

On Wed, Sep 26, 2018 at 2:04 PM Lawrence Finch via dmarc-discuss <
dmarc-discuss@dmarc.org> wrote:

>
>
> On Sep 26, 2018, at 4:44 PM, Bongaerts Contract via dmarc-discuss <
> dmarc-discuss@dmarc.org> wrote:
>
> Hello, Would someone please be kind enough to tell me how to Unsubscribe
> from these emails ?
>
> Thank you.
>
> Carl BongaertsTel: 416-831-7841
>
>
> You raise a really good question. The list violates US federal regulations
> by not providing instructions in every message about how to unsubscribe.
> And I just went to the Info page for the list, and there were no
> instructions to unsubscribe there either.
>
> --
> Larry Finch
> finc...@portadmiral.org
>
>
>
> ___
> 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] Help

[Brandon Long via dmarc-discuss]

Use a null mx instead.
https://tools.ietf.org/html/rfc7505

On Wed, Sep 26, 2018, 8:43 AM Al Iverson via dmarc-discuss <
dmarc-discuss@dmarc.org> wrote:

> Might be better to have an MX record that points to localhost, because
> if you have an A record but no MX, people will just try to connect to
> the A record.
>
> Though I've never tried it for domains that lack an MX DNS entry, I do
> think overall that DMARC (and SPF) are both good things to configure
> for domains that don't send email. I've blogged about it here:
> https://www.spamresource.com/2018/06/locking-down-your-unused-domains.html
>
> Cheers,
> Al
> On Wed, Sep 26, 2018 at 9:52 AM Zachary Aab via dmarc-discuss
>  wrote:
> >
> > The sub/domain should be protected by the DMARC record even without an
> MX record, I can't find anything in the RFC to say otherwise and some
> senders (mostly marketing, ime) use 5322.from domains with no MX records
> and a "Reply-to:" header with a working domain.
> >
> > >Could the syntax error caused by the receiving domain may not have the
> txt record to authorize the reports reception?
> > It certainly could, of course we can't check up on that without the
> domain.  The answer will probably depend on what is actually throwing the
> syntax error, is it a DMARC-checking tool on the internet, a receiver's
> DMARC filter, or your DNS provider?
> >
> > It looks like your last clause (rua=) is missing the semicolon at the
> end, receivers will care about that to varying degrees but it might be
> causing the error you see, again depending on what's giving the error.
> >
> > My best,
> > Zack Aab
> >
> >
> > On Tue, Sep 25, 2018 at 9:37 PM T Nguyen via dmarc-discuss <
> dmarc-discuss@dmarc.org> wrote:
> >>
> >> Could the syntax error caused by the receiving domain may not have the
> txt record to authorize the reports reception?
> >>
> >>
> >>
> >> From: T Nguyen 
> >> Sent: Tuesday, September 25, 2018 9:30 PM
> >> To: dmarc-discuss@dmarc.org
> >> Subject: Help
> >>
> >>
> >>
> >> Appreciate any insight to the scenario below:
> >>
> >>
> >>
> >> Can non-smtp ( no mx record ) domain example.com be protected by
> dmarc?  I inherited the below dmarc record for this example.com with  spf
> record as “ v=spf1 -all “.  The result was a dmarc syntax error.
> >>
> >>
> >>
> >> v=DMARC1; p=reject; pct=100; rua=mailto:dmarc-repo...@not-example.com
> ,mailto:repo...@example-not.com
> >>
> >>
> >>
> >> If dmarc cannot be implemented then what is the best way to protect
> this non-smtp domain example.com from being spoofed by mal-intention
> senders that can fool naïve users?  Although with spf record “ v=spf1 -all
> “alone should work for dmarc record to set policy reject all email using
> this non-email domain example.com
> >>
> >>
> >>
> >> Thank you in advance,
> >>
> >> Best,
> >>
> >> tn
> >>
> >> ___
> >> 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)
>
>
>
> --
> al iverson // 312-725-0130 // miami
> http://www.aliverson.com
> http://www.spamresource.com
>
> ___
> dmarc-discuss mailing list
> dmarc-discuss@dmarc.org
> http://www.dmarc.org/mailman/listinfo/dmarc-discuss
>
> NOTE: Participating in this list means you agree to the DMARC Note Well
> terms (http://www.dmarc.org/note_well.html)
___
dmarc-discuss mailing list
dmarc-discuss@dmarc.org
http://www.dmarc.org/mailman/listinfo/dmarc-discuss

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

Re: [dmarc-discuss] MS mail servers (outlook, office365)

[Brandon Long via dmarc-discuss]

On Fri, Jul 13, 2018 at 11:20 AM John Levine via dmarc-discuss <
dmarc-discuss@dmarc.org> wrote:

> In article <
> sc1p15201mb2608185f150e2f40a5f89fb4c3...@sc1p15201mb2608.lamp152.prod.outlook.com>
> you write:
> >Guys, I'm looking for the RUA coming from MS mail servers, but I just
> didn't see any.
>
> I have regular reports through October 2017, then four reports this
> year, the last one in April.
>
> I assume this means they've stopped sending reports, not that they've
> stopped looking at DMARC.
>

https://blogs.msdn.microsoft.com/tzink/2018/05/21/a-way-to-sort-of-approximate-dmarc-aggregate-reports-in-office-365/

O365 doesn't support them, and they've migrated most of
Hotmail/Outlook/Live to O365, so perhaps that's why they're gone.

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

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

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

[Brandon Long via dmarc-discuss]

On Tue, May 29, 2018 at 8:10 AM Alessandro Vesely via dmarc-discuss <
dmarc-discuss@dmarc.org> wrote:

> On Tue 29/May/2018 01:27:33 +0200 Roland Turner via dmarc-discuss wrote:
> > On 28/05/18 19:26, Alessandro Vesely via dmarc-discuss wrote:
> >
> > For the implied question ("Why would small guys be interested?"):
> >
> >  * ARC headers simply provide a view as to what happened upstream.
> >Whatever effort you're willing to invest in hand-to-hand fighting is
> >amplified (greater efficiency and/or effectiveness) simply by making
> >use of that visibility.
> >  * A single public whitelist is not necessary for ARC to work, multiple
> >lists are certainly possible, but the mapping of well-behaved
> >whitelist operators is:
> >  o much easier than mapping abusers, as the latter are seeking to
> >_*evade*_ detection;
> >  o much slower moving (new small list operators appear at a rate of
> >perhaps one per week; abusers gain control of IP addresses at a
> >rate of many per second); and
> >  o more resilient in that possession of the abuse data by abusers
> >doesn't provide a means to optimise abuse by focusing on IP
> >addresses and identifiers that haven't yet been identified[1],
> >
> >meaning that a slow-moving list can be included in email
> >security software, as with the current rule set for something
> >like SpamAssassin.
>
> You seem to imply that only mailing list activity needs to deploy ARC.
>
> I know ARC proponents don't want author's domains to sign ARC-0, but never
> understood why.  Anyway, ordinary forwarders will need to ARC sign
> forwarded
> messages too, which includes pretty much all mail sites.  The latter is
> *not* a
> slow-moving data set.  It grows steadily.
>

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

As for ARC-0, there's no need for the actual From domain to sign as ARC,
that's what DKIM/SPF are for.  If you're talking about
a third party author, that's a very different trust statement.

Ie, for regular ARC forwarding, the trust is that they implement ARC
correctly and are not faking the ARC results.
For ARC-0, the trust is that the "author" domain has permission to send on
behalf of another domain.  What that permission
looks like can vary greatly, from say the simplest level of "email address
confirmation" to some level of live user query.

Ie, the simple confirmation won't typically do a good job of preventing an
ex-employee who already registered with a third party service from sending
mail as that service, unless you required every sent message to first have
a confirmation via email to the sender.  Is that really a useful level of
service to justify ARC-0?

I'm sure there are vendors who would benefit from that, typically those
sending larger volumes of messages for users from domains that don't
support that, ie your small business using an @gmail.com address and using
say Constant Contact.  But is Gmail really going to trust a third party to
send mail on it's behalf (pretty sure the answer would be no).

Another use case would be "having my hosted domains set up SPF/DKIM is too
hard, I'll just sign for them".  I can see some utility in that, but it has
the same "how do I know that?"  Ie, we probably have some documentation on
how we manage domain ownership for GSuite domains and enforce that
ownership, and even if we do an excellent job with that, there's almost
certainly some grace period involved in verification failures, during which
the ex-domain owner would still be able to send mail as the domain.  We've
even debating doing something like that for Gmail to Gmail mail when we had
some big issues with a prominent DNS provider having outages.  I still have
a hard time believing the rest of the world wants to just say "trust
anything Gmail sends as authed".

Really, the solution for ARC-0 is probably MSA with OAUTHBEARER, which
allows for an individual to auth a specific sender for their own address,
and enforces all of the regular controls for the account, and allows the
individual to list and manage those auths.  It won't help the cases where
they want to use their address for higher volume, though.

Brandon
___
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 DKIM Signature Reporting in DMARC

[Brandon Long via dmarc-discuss]

Another question would be, should we add the algorithm to the dkim section
to differentiate?

On Sat, Apr 21, 2018 at 11:43 PM Scott Kitterman via dmarc-discuss <
dmarc-discuss@dmarc.org> wrote:

> On Sunday, April 22, 2018 02:12:33 PM Roland Turner via dmarc-discuss
> wrote:
> > On 21/04/18 05:36, Scott Kitterman via dmarc-discuss wrote:
> > > As most of you already know, the DCRUP working group is adding a new
> > > signature algorithm to DKIM.  I have been sending dual
> > > rsa-sha256/ed25519-sha256 signed mail for some time and I have notice
> an
> > > oddity in DMARC reporting.>
> > > Typically, I'll see something like this XML snippet:
> > > 
> > >
> > > 
> > >
> > > kitterman.com
> > > pass
> > > 201803r
> > >
> > > 
> > > 
> > >
> > > kitterman.com
> > > fail
> > > 201803e
> > >
> > > 
> > >
> > > The first one is the rsa-sha256 signature and the second, marked fail,
> is
> > > the ed25519-sha256 signature (I can tell based on the selector).  In
> all
> > > cases I've checked, the correct (DMARC pass) result was obtained, but I
> > > don't think this is the best way to report it.
> >
> > It would be helpful for the receiver to explain that the problem is an
> > interoperability one rather than an asserted failure of an implemented
> > algorithm, certainly.
> >
> > > RFC 6376 says:
> > >> 3.3.4.  Other Algorithms
> > >>
> > >> Other algorithms MAY be defined in the future.  Verifiers MUST
> ignore
> > >> any signatures using algorithms that they do not implement.
> > >
> > > I'm not sure reporting a failure is consistent with "MUST ignore".  In
> any
> > > case, I think it would be useful to distinguish between DKIM evaluation
> > > failed and not evaluated due to unknown algorithm in DMARC reporting.
> >
> > There are half a dozen things which must be ignored if not supported
> > (canonicalisations, etc.), but the obligation to ignore doesn't appear
> > to imply an obligation not to report by whatever means are appropriate,
> > only that the ignored elements must be removed from consideration prior
> > to computing a pass.
> >
> > More directly, in 6.3 Interpret Results/Apply Local Policy:
> > > If the email cannot be verified, then it SHOULD be treated the same
> > > as all unverified email, regardless of whether or not it looks like
> > > it was signed.
> >
> > This would appear to encourage treating 3.3.4 cases in the same way as
> > all unverified email, i.e. reporting a fail, as the example you quote
> > does. I do note that RFC 7601 - whose results RFC 7489 uses -
> > establishes separate criteria for none, fail, policy, and neutral. It
> > might be argued that neutral is a better fit for reporting the use of a
> > signature algorithm not supported by the verifier:
> >
> > none:  The message was not signed.
> >
> > pass:  The message was signed, the signature or signatures were
> >acceptable to the ADMD, and the signature(s) passed verification
> >tests.
> >
> > fail:  The message was signed and the signature or signatures were
> >acceptable to the ADMD, but they failed the verification test(s).
> >
> > policy:  The message was signed, but some aspect of the signature or
> >signatures was not acceptable to the ADMD.
> >
> > neutral:  The message was signed, but the signature or signatures
> >contained syntax errors or were not otherwise able to be
> >processed.  This result is also used for other failures not
> >covered elsewhere in this list.
> >
> >
> > Would using neutral with some explanatory text in a human_result element
> > suit, or would you advocate the addition of "unsupported" (or similar)
> > to 7601 and 7489?
>
> I think neutral is reasonable.  I'd add to the definition above that the
> signature was not used for DMARC evaluation.  Neutral is what multiple
> implementations already report in their authentication results header
> fields
> for these signatures:
>
> Authentication-Results: mx.google.com;
>dkim=neutral (no key) header.i=@kitterman.com header.s=201803e
> header.b=hxFQlnEt;
>
> Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=neutral
>  reason="invalid (unsupported algorithm ed25519-sha256)"
>  header.d=kitterman.com header.b=INr2EzUJ;
>
> 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 

Re: [dmarc-discuss] DSN from microsoftonline.com

[Brandon Long via dmarc-discuss]

On Wed, Dec 20, 2017 at 1:48 PM A. Schulze via dmarc-discuss <
dmarc-discuss@dmarc.org> wrote:

>
>
> Am 20.12.2017 um 18:44 schrieb Roland Turner via dmarc-discuss:
> > What HELO/EHLO hostname is being presented?
>
> I'm out of office for the next days and have no access to that data.
> From what I remember it's the hostname of the sending system, a rDNS
> related to Microsoft.
>
> Why do you think, the EHLO is important?
>

For bounces (ie, empty MAIL FROM), the EHLO argument is used for the SPF
lookup, so it is technically possible for there to be a valid SPF record.

That said, I wouldn't bet on it.  I know there's still an open bug to
create the DNS SPF records for our EHLO hostnames at Google, it was just
never a high priority.  Plus, it wouldn't really help the DMARC case
because our DSN's come from @googlemail.com for some reason I was never
clear on but our EHLO hostnames are google.com.

Brandon
___
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 authentication issues with Google

[Brandon Long via dmarc-discuss]

There are multiple services, such as Valimail or Dmarcian or whatever which
can help you make that decision, though perhaps they're all a bit biased
towards actually making the transition to quarantine/reject.

It may be possible to switch to quarantine until the blast is contained.
You do have multiple months of data to see what would be affected.  That's
also what I imagine these companies spend a lot of effort on is helping you
identify what sending services will be affected when you make the switch.

Brandon


On Sat, Dec 9, 2017 at 2:10 PM The Venus Project Postmaster <
postmas...@thevenusproject.com> wrote:

> Thanks for the information and suggestions. It was helpful.
>
> I've been monitoring https://postmaster.google.com for the last two
> months and, surprisingly, DMARC authentication was consistently at 100%
> that entire time, right since after I posted my message to this list. But a
> few days ago, about December 5th, it dropped to almost 0%. See attached
> image.
>
> I then cross-checked with the feedback reports (we get those in
> dmarcian.com) and it looks like right at December 5th there was a big
> spike in fraudulent emails pretending to be sent from our domain. See
> attached screenshot from dmarcian.com's interface.
>
> So the DMARC authentication percentage in the Google Postmaster Tool would
> indeed appear to be separate/independent from the SPF and DKIM
> authentication. That does seem counterintuitive to me.
>
> Would you have any recommendation on DMARC policy to use in this
> situation? I don't know if p=quarantine would be justified with such an
> amount of fraudulent senders. I imagine if we make our policy p=quarantine,
> some genuine emails might end up in recipients' Spam folders due to
> whatever temporary technical glitches with authentication, so I am not too
> sure how to weigh the positives and negatives of such policy change. I also
> don't know what damage these fraudulent senders might be causing to our
> domain reputation or anything else.
>
> Thanks,
> Borislav
> The Venus Project Postmaster Team
> www.thevenusproject.com
>
> On 10/5/2017 9:18 PM, Brandon Long wrote:
>
> That graph is awful, especially how it's conflating those three things.
>
> My guess (I don't know much about the postmaster tools), is that SPF is
> only judging what has an envelope sender for your domain, DKIM is only
> judging what has a DKIM signature, and DMARC is judging what is "From" your
> domain.
>
> Given that is has "dmarc" on it, you'd think the graph would be about
> dmarc and alignment, and the three lines would all be judged on the same
> messages, but I'm guessing it's not.  Ie, you'd think it was all messages
> From your domain, and then the dmarc output would match where spf and dkim
> failed.
>
> My guess is what you're seeing is because you're p=none, and so some of
> your messages which have your From domain are being sent through GSuite
> mailing lists (which are used for most GSuite aliases like
> sa...@gsuitecustomer.com, so quite common), and because you're p=none, we
> don't rewrite the From, and we do remove the DKIM signature (since it would
> be broken) and the envelope sender will be the list (so not affecting your
> SPF).  This will likely be what you find in your dmarc aggregate report.
> If you were to go p=quarantine or reject, GSuite Groups would start
> rewriting the from and the dmarc failures would likely go down or away for
> you.
>
> Brandon
>
> On Thu, Oct 5, 2017 at 4:24 AM, Roland Turner via dmarc-discuss <
> dmarc-discuss@dmarc.org> wrote:
>
>> Is the information in this graph consistent with what's in Google's
>> aggregate feedback? (This is to determine whether Google's DMARC
>> implementation is broken, or just the postmaster tool.)
>>
>> - Roland
>>
>>
>>
>> On 05/10/17 18:51, The Venus Project Postmaster via dmarc-discuss wrote:
>>
>> Hi everyone,
>>
>> For the past several months we have been experiencing ups and downs in
>> our DMARC authentication with Gmail, as seen from Google's postmaster tool
>> (see attached screenshot). DKIM and SPF authentication are consistently at
>> 100%, but DMARC authentication varies wildly, although there have been no
>> configuration changes on our side.
>>
>> Our DMARC DNS record seems to be set up properly.
>>
>> Some time ago I contacted the Google postmaster team through their
>> feedback form, but nothing followed.
>>
>> Does anyone have any suggestions on what could be causing this (could it
>> be anything on our end?) and what we could do to resolve it?
>>
>> Thanks in advance,
>> Borislav
>> The Venus Project Postmaster Team
>> www.thevenusproject.com
>>
>>
>> ___
>> dmarc-discuss mailing 
>> listdmarc-discuss@dmarc.orghttp://www.dmarc.org/mailman/listinfo/dmarc-discuss
>>
>> NOTE: Participating in this list means you agree to the DMARC Note Well 
>> terms (http://www.dmarc.org/note_well.html)
>>
>>
>>
>> ___
>> 

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

[Brandon Long via dmarc-discuss]

ballparking my current reports, I'd say less than the 16k unique domains
you're sending to, assuming you're asking about aggregate.

Brandon


On Fri, Nov 17, 2017 at 9:56 AM DMARC via dmarc-discuss <
dmarc-discuss@dmarc.org> wrote:

> Any ideas how many DMARC reports would actually be sent to the sending
> domain ? The organization, behind my question, sends to approx. 16k unique
> domains/day.
>
> I understand we can start with a low percentage configuration, but I'm
> still trying to ballpark the circumstances.
>
> Thanks for any input, Jack
> ___
> 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] Google not sending aggregate reports for my .US TLD

[Brandon Long via dmarc-discuss]

yeah, seems reasonable, I'll file a bug.

Brandon


On Fri, Oct 27, 2017 at 3:44 PM Steve Atkins via dmarc-discuss <
dmarc-discuss@dmarc.org> wrote:

>
> > On Oct 27, 2017, at 3:15 PM, Tyler South via dmarc-discuss <
> dmarc-discuss@dmarc.org> wrote:
> >
> > The domain in question is cssi.us
> >
> > Thanks for any assistance you can provide.
> >
>
> Looks reasonable to me.
>
> v=DMARC1;rua=mailto:983a6a4164b9...@rep.dmarcanalyzer.com,mailto:
> dmarc...@cssi.us;ruf=mailto:983a6a4164b9...@for.dmarcanalyzer.com,mailto:
> dmarc...@cssi.us; p=reject; fo=1; sp=none
>
> http://tools.wordtothewise.com/dmarc/check/cssi.us
>
> Maybe someone at Google can take a look?
>
> Cheers,
>   Steve
>
> > On Fri, Oct 27, 2017 at 5:08 PM, Tyler South  wrote:
> > Hey everyone,
> >
> >
> > We’ve been trying to track down what could possibly be causing this
> issue. Google nevers send an aggregate report for our .US domain.
> >
> >
> >
> > We get aggregate reports from AOL, Yahoo, and Outlook on occasion but
> have yet to get a single report from Google.
> >
> >
> > We use this very same .US domain to receive DMARC reports, both
> aggregate and forensic, for  about ten other domains that we manage. Google
> sends us aggregate reports about those domains every day.
> >
> >
> > So we do get aggregate reports from Google for other domains in which we
> are setup as the rua.We just don't get them for our own domain.
> >
> >
> > The DMARC record for our domain is, "v=DMARC1;rua=mailto:
> aggrepo...@x.us;ruf=mailto:forrepo...@x.us; p=reject; fo=1;
> sp=none"
> >
> >
> > We have modified it several times in failed attempts to resolve this
> issue. We tried changing the RUA to other domains and services such as
> DMARCAnalyzer and we have pretty much tried everything as far as changing
> tags in the DMARC record goes.
> >
> >
> > Here is a copy of a DMARC record for a domain that google DOES send
> reports for to us, "v=DMARC1;rua=mailto:aggrepo...@x.us;ruf=mailto:
> forrepo...@x.us; p=reject; fo=1;"
> >
> >
> > We can’t figure out any pattern to this madness.
> >
> >
> > I mentioned our domain being a .US TLD repeatedly because I’m almost
> convinced there is a bug that has something to do with reports not being
> generated for a .US TLD.
> >
> >
> > Can anyone else with a .US TLD confirm you get reports from Google?
> >
> >
> >
> > If anyone has any ideas we’d really appreciate your time. This has been
> driving us mad.
> >
> >
> > Thanks.
> >
> >
> > ___
> > 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] Google not sending aggregate reports for my .US TLD

[Brandon Long via dmarc-discuss]

Isn't .us usually considered a 3 level tld, like .uk and .au?  And DMARC
says to ignore tlds.

Brandon


On Fri, Oct 27, 2017 at 3:01 PM Steve Atkins via dmarc-discuss <
dmarc-discuss@dmarc.org> wrote:

>
> > On Oct 27, 2017, at 2:08 PM, Tyler South via dmarc-discuss <
> dmarc-discuss@dmarc.org> wrote:
> >
> > Hey everyone,
> >
> >
> > We’ve been trying to track down what could possibly be causing this
> issue. Google nevers send an aggregate report for our .US domain.
> >
> >
> >
> > We get aggregate reports from AOL, Yahoo, and Outlook on occasion but
> have yet to get a single report from Google.
> >
> >
> > We use this very same .US domain to receive DMARC reports, both
> aggregate and forensic, for  about ten other domains that we manage. Google
> sends us aggregate reports about those domains every day.
> >
> >
> > So we do get aggregate reports from Google for other domains in which we
> are setup as the rua.We just don't get them for our own domain.
> >
> >
> > The DMARC record for our domain is, "v=DMARC1;rua=mailto:
> aggrepo...@x.us;ruf=mailto:forrepo...@x.us; p=reject; fo=1;
> sp=none"
>
> p=reject and sp=none?
>
> >
> >
> > We have modified it several times in failed attempts to resolve this
> issue. We tried changing the RUA to other domains and services such as
> DMARCAnalyzer and we have pretty much tried everything as far as changing
> tags in the DMARC record goes.
> >
> >
> > Here is a copy of a DMARC record for a domain that google DOES send
> reports for to us, "v=DMARC1;rua=mailto:aggrepo...@x.us;ruf=mailto:
> forrepo...@x.us; p=reject; fo=1;"
> >
> >
> > We can’t figure out any pattern to this madness.
>
> It does sound like something at Google and something in your DMARC record
> may not be playing nice together. Do you get forensic reports for that
> domain?
>
> >
> >
> > I mentioned our domain being a .US TLD repeatedly because I’m almost
> convinced there is a bug that has something to do with reports not being
> generated for a .US TLD.
>
> You might get more useful advice if you share what the relevant domains
> are, so we can look up what DMARC records you're publishing (and maybe
> check logs for those domains).
>
> Cheers,
>   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] Report domain from google.com

[Brandon Long via dmarc-discuss]

can you be more specific about what your concern is?

Brandon

On Thu, Oct 19, 2017 at 3:32 PM, Sugeng Novianto via dmarc-discuss <
dmarc-discuss@dmarc.org> wrote:

> Got a non-standart e-mails from google about my domain DMARC.
>
> Report domain: x.com Submitter: google.com Report-ID:
> 12282064853522992200
>
>
>
> ___
> 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 authentication issues with Google

[Brandon Long via dmarc-discuss]

That graph is awful, especially how it's conflating those three things.

My guess (I don't know much about the postmaster tools), is that SPF is
only judging what has an envelope sender for your domain, DKIM is only
judging what has a DKIM signature, and DMARC is judging what is "From" your
domain.

Given that is has "dmarc" on it, you'd think the graph would be about dmarc
and alignment, and the three lines would all be judged on the same
messages, but I'm guessing it's not.  Ie, you'd think it was all messages
>From your domain, and then the dmarc output would match where spf and dkim
failed.

My guess is what you're seeing is because you're p=none, and so some of
your messages which have your From domain are being sent through GSuite
mailing lists (which are used for most GSuite aliases like
sa...@gsuitecustomer.com, so quite common), and because you're p=none, we
don't rewrite the From, and we do remove the DKIM signature (since it would
be broken) and the envelope sender will be the list (so not affecting your
SPF).  This will likely be what you find in your dmarc aggregate report.
If you were to go p=quarantine or reject, GSuite Groups would start
rewriting the from and the dmarc failures would likely go down or away for
you.

Brandon

On Thu, Oct 5, 2017 at 4:24 AM, Roland Turner via dmarc-discuss <
dmarc-discuss@dmarc.org> wrote:

> Is the information in this graph consistent with what's in Google's
> aggregate feedback? (This is to determine whether Google's DMARC
> implementation is broken, or just the postmaster tool.)
>
> - Roland
>
>
>
> On 05/10/17 18:51, The Venus Project Postmaster via dmarc-discuss wrote:
>
> Hi everyone,
>
> For the past several months we have been experiencing ups and downs in our
> DMARC authentication with Gmail, as seen from Google's postmaster tool (see
> attached screenshot). DKIM and SPF authentication are consistently at 100%,
> but DMARC authentication varies wildly, although there have been no
> configuration changes on our side.
>
> Our DMARC DNS record seems to be set up properly.
>
> Some time ago I contacted the Google postmaster team through their
> feedback form, but nothing followed.
>
> Does anyone have any suggestions on what could be causing this (could it
> be anything on our end?) and what we could do to resolve it?
>
> Thanks in advance,
> Borislav
> The Venus Project Postmaster Team
> www.thevenusproject.com
>
>
> ___
> dmarc-discuss mailing 
> listdmarc-discuss@dmarc.orghttp://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] No DMARC from Google again?

[Brandon Long via dmarc-discuss]

We're aware of the issue and investigating.

On Aug 16, 2017 7:36 AM, "Randal Pinto via dmarc-discuss" <
dmarc-discuss@dmarc.org> wrote:

> Anyone got DMARC reports from Google? Last one I got was on 13/Aug.
> Capacity problems again?
>
> --
> Randal Pinto
> Founder & COO
> +447703108205
> @randalpinto 
>
> *Red Sift
>  powers OnDMARC
> *
> 5th Floor, 43 Whitfield Street, W1T 4HD, London, UK.
>
> *News*: OnDMARC wins Cyber Security Start-Up of the Year
> 
>  | OnDMARC joins G-Cloud 9
> 
>
> ___
> 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] Fwd: DMARC report interpretation

[Brandon Long via dmarc-discuss]

My guess would be a google groups mailing list, which doesn't rewrite
because you're only p=none.  It's pretty common for domains to use  mailing
lists as aliases with gsuite, so sa...@foo.com would be a mailing list and
do the resending.

There's several less than ideal things about this in this instance for
dmarc reporting, though individually were useful at the time.  I'm sure
fixing them are down at the bottom of some long list if improvements to
make.

Brandon

On Jun 19, 2017 8:38 AM, "John Wilson via dmarc-discuss" <
dmarc-discuss@dmarc.org> wrote:

> I suspect this is a relay/autoforward situation. The recipient at
> otherdomain.com likely has an autoforward rule configured so when you
> send mail to that individual it's routed to some other mailbox. Google
> signs the message and modifies the envelope sender when forwarding.
>
> On Sun, Jun 18, 2017 at 11:26 PM, PenguinWhispererThe . via dmarc-discuss
>  wrote:
>
>> Hi all,
>>
>> I've recently set up DMARC, SPF and DKIM. I'm now checking all DMARC
>> reports I'm receiving. I've noticed the below entry which looks like an IP
>> which is outside my control and is also not of a usual sender (the entries
>> that are legit are usually coming from 2 ISP mailservers and I see those
>> IPs on a daily basis). So this one entry seems to be off.
>>
>> Now I wonder what I should conclude from this DMARC entry.
>> Is this an email server, which successfully auths (using SPF and DKIM, so
>> I can be "assured" it's actually the mailserver intended for
>> otherdomain.com?) sending out an email in the name of mydomain.com?
>> Note that mydomain.com is doing business with otherdomain.com. So
>> perhaps I'm reading this entry incorrectly. However I don't see any
>> incoming email for mydomain.com from them at that time which would mean
>> this must have been a mail addressed to another domain.
>>
>> I don't see any reason why this company would need to send emails in name
>> of my domain. I know I can change the policy using DMARC to drop such
>> emails but nonetheless it seems interesting to investigate what's going on
>> here.
>>
>> Am I interpreting this entry correctly? Thanks a lot in advance.
>>
>> 
>>   
>> w.x.y.z
>> 4
>> 
>>   none
>>   fail
>>   fail
>> 
>>   
>>   
>> mydomain.com
>>   
>>   
>> 
>>   otherdomain-com.20150623.gappssmtp.com
>>   pass
>>   20150623
>> 
>> 
>>   otherdomain.com
>>   pass
>> 
>>   
>> 
>>
>>
>>
>> ___
>> 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] Metrics on policy actions

[Brandon Long via dmarc-discuss]

Are you looking for the policy applied or the policy requested?  Also, I
would imagine this is heavily different depending on the receiver.

Brandon

On Tue, Apr 25, 2017 at 6:23 AM, Anthony Purcell via dmarc-discuss <
dmarc-discuss@dmarc.org> wrote:

> Hi John,
>
> I'm looking for something simpler. A breakdown of how much mail was
> p=reject,accept,quarantine
>
> 10% accept
> 40% quarantine
>
> Make sense?
>
> Thanks,
> 
>
> On Apr 24, 2017, at 17:12, John Wilson  wrote:
>
> Anthony,
>
> Do you mean "versus local policy-overrides"?
>
> John
>
> On Mon, Apr 24, 2017 at 4:33 PM, Anthony Purcell via dmarc-discuss <
> dmarc-discuss@dmarc.org> wrote:
>
>> Hello,
>>
>> I was wondering if any dmarc implementors had any stats on what
>> percentage of your mail stream matches the various polices? Or if there is
>> a maawg doc out there someone could point me to that would be great.
>> ___
>> 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] Netscape.net?

[Brandon Long via dmarc-discuss]

Er, that's 3/23, ie yesterday.

On Fri, Mar 24, 2017 at 3:39 PM, Brandon Long  wrote:

> From our recent logs, it looks like it was updated from p=none to p=reject
> on sometime around 2/23 1p PDT ... probably because of this note.
>
> Brandon
>
> On Fri, Mar 24, 2017 at 12:52 PM, John Levine via dmarc-discuss <
> dmarc-discuss@dmarc.org> wrote:
>
>> In article > ail.com> you write:
>> >
>> >One of our mailing list members, with a netscape.net email address, is
>> >getting DMARC bounces. That domain is set to p=none.
>>
>> That hasn't been the case for quite a while.
>>
>> $ dig _dmarc.netscape.net txt
>>
>> ;; QUESTION SECTION:
>> ;_dmarc.netscape.net.   IN  TXT
>>
>> ;; ANSWER SECTION:
>> _dmarc.netscape.net.60  IN  TXT "v=DMARC1; p=reject;
>> fo=1; pct=100; ri=3600; rua=mailto:a...@rua.agari.com; ruf=mailto:
>> a...@ruf.agari.com"
>>
>> R's,
>> John
>> ___
>> dmarc-discuss mailing list
>> dmarc-discuss@dmarc.org
>> http://www.dmarc.org/mailman/listinfo/dmarc-discuss
>>
>> NOTE: Participating in this list means you agree to the DMARC Note Well
>> terms (http://www.dmarc.org/note_well.html)
>>
>
>
___
dmarc-discuss mailing list
dmarc-discuss@dmarc.org
http://www.dmarc.org/mailman/listinfo/dmarc-discuss

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

Re: [dmarc-discuss] Netscape.net?

[Brandon Long via dmarc-discuss]

>From our recent logs, it looks like it was updated from p=none to p=reject
on sometime around 2/23 1p PDT ... probably because of this note.

Brandon

On Fri, Mar 24, 2017 at 12:52 PM, John Levine via dmarc-discuss <
dmarc-discuss@dmarc.org> wrote:

> In article  gmail.com> you write:
> >
> >One of our mailing list members, with a netscape.net email address, is
> >getting DMARC bounces. That domain is set to p=none.
>
> That hasn't been the case for quite a while.
>
> $ dig _dmarc.netscape.net txt
>
> ;; QUESTION SECTION:
> ;_dmarc.netscape.net.   IN  TXT
>
> ;; ANSWER SECTION:
> _dmarc.netscape.net.60  IN  TXT "v=DMARC1; p=reject;
> fo=1; pct=100; ri=3600; rua=mailto:a...@rua.agari.com; ruf=mailto:
> a...@ruf.agari.com"
>
> R's,
> John
> ___
> dmarc-discuss mailing list
> dmarc-discuss@dmarc.org
> http://www.dmarc.org/mailman/listinfo/dmarc-discuss
>
> NOTE: Participating in this list means you agree to the DMARC Note Well
> terms (http://www.dmarc.org/note_well.html)
>
___
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?

[Brandon Long via dmarc-discuss]

Actually, do you have any more specifics for me to take a look?  Best case
would be the recipient and message-id of something that ended up in the
spam label.

Off list would be fine.

Brandon

On Fri, Feb 3, 2017 at 5:05 PM, Brandon Long  wrote:

> I'll take a look.
>
> On Thu, Feb 2, 2017 at 11:28 PM, Roland Turner <
> roland.tur...@trustsphere.com> wrote:
>
>> John Payne wrote:
>>
>> >> Presumably this just indicates that the rewrite rule that Brandon
>> described for Google Groups
>> >> is not in use by IETF's mailing lists?
>> >>
>> >> Tradeoffs in every direction...
>> >
>> > I wasn't expecting behavior changes for ietf mail.
>> >
>> > To clarify, with p=none I had no complaints. With p=quarantine, pct=0 I
>> have complaints from gmail users.
>> >
>> > I believe this points to gmail perhaps not looking at the pct...
>>
>> Apologies, wrote before thinking it through. What should have happened is
>> that the failures identified in aggregate reports should have gone down as
>> Google Groups would rewrite because of it, but that no changes in receiver
>> behaviour should occur.
>>
>> I agree, this looks like a Gmail bug.
>>
>> Brandon, are you able to explore this with your colleagues?
>>
>> - 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)

Re: [dmarc-discuss] A bit quiet?

[Brandon Long via dmarc-discuss]

I'll take a look.

On Thu, Feb 2, 2017 at 11:28 PM, Roland Turner <
roland.tur...@trustsphere.com> wrote:

> John Payne wrote:
>
> >> Presumably this just indicates that the rewrite rule that Brandon
> described for Google Groups
> >> is not in use by IETF's mailing lists?
> >>
> >> Tradeoffs in every direction...
> >
> > I wasn't expecting behavior changes for ietf mail.
> >
> > To clarify, with p=none I had no complaints. With p=quarantine, pct=0 I
> have complaints from gmail users.
> >
> > I believe this points to gmail perhaps not looking at the pct...
>
> Apologies, wrote before thinking it through. What should have happened is
> that the failures identified in aggregate reports should have gone down as
> Google Groups would rewrite because of it, but that no changes in receiver
> behaviour should occur.
>
> I agree, this looks like a Gmail bug.
>
> Brandon, are you able to explore this with your colleagues?
>
> - 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)

Re: [dmarc-discuss] A bit quiet?

[Brandon Long via dmarc-discuss]

Someone asked a followup question here, and something else occurred to me.

If you go to p=quarantine and pct=0, Google Groups will still do the
rewriting, but no one should enforce the quarantine.  I know this is true
for our own code, but I don't know how well others handle it to know if
it's a safe thing to do or not.

Brandon

On Fri, Oct 28, 2016 at 4:30 PM, Brandon Long  wrote:

> This sounds likely to be messages from your domain that were forwarded by
> Google apps, most likely mailing lists.
>
> If the message was authenticated inbound to the mailing list, it will be
> signed outbound by the domain hosting the list.
>
> If you were p=reject or quarantine, we would rewrite the from.  It's
> unfortunate that we don't rewrite while you are p=none, I'm unsure whether
> we should change that or wait for arc.
>
> As everyone knows, rewriting isn't a great experience, which is why we
> haven't done it for p=none, but if it makes the reporting too annoying to
> go to p=reject, we should rethink.
>
> Also, if you're using a third party to analyse your rua reports, perhaps
> they should do more to help for this case.
>
> Would it help if we reported these as a passed by local policy, since they
> would by xoar?
>
> Brandon
>
> On Oct 27, 2016 8:19 PM, "Roland Turner via dmarc-discuss" <
> dmarc-discuss@dmarc.org> wrote:
>
>> John,
>>
>>
>> My apologies, I appear to have misinterpreted this completely, not sure
>> what I was thinking:
>>
>>- DMARC reports are sent to the address specified in the DMARC record
>>associated with the 5322.From address, not the source IP addresses.
>>- Therefore, these reports are sent to you because the 5322.From
>>header contains an akamai.com address.
>>- The examples that you're citing showing a 5321.MailFrom address
>>(with SPF pass) and DKIM d= domain (with DKIM pass) that are aligned with
>>each other. This suggests either (a) a message sent legitimately by
>>yourselves and legitimately forwarded or (b) an impersonation, also 
>> legitimately
>>forwarded. It is to be hoped that Google's DMARC reports
>>preferentially report on DMARC-aligned DKIM passes if they're present,
>>suggesting that the messages in question are passing through DKIM-breaking
>>forwarding (case (a)) or lack DKIM signatures (hopefully case (b)).
>>
>> I'm guessing that you'd already worked this out.
>>
>>
>> The forwarding cases are the awkward corner case for DMARC. As a domain
>> owner/registrant there's probably not much that you can do about this.
>> Someone like PayPal can, because of the stakes involved, stipulate that
>> users (a) provide an end-address and (b) not forward it. I don't imagine
>> that you're in a position to do so. ARC goes some way to helping receivers
>> make better decisions, but that doesn't give you much to work with.
>>
>>
>> Is there email sent legitimately with an @akamai.com email address that
>> isn't from an Akamai employee or automated system? If so, are the stakes
>> high enough that you're in a position to direct employees to avoid using
>> their work email addresses for mailing lists? (This won't solve the
>> problem, but may significantly reduce it.) Are you able to quantify the
>> damage being done at present? (If not, stop work on this now!)
>>
>>
>> - Roland
>>
>> --
>> *From:* Payne, John 
>> *Sent:* Friday, 28 October 2016 04:45
>> *To:* Roland Turner
>> *Cc:* DMARC Discussion List
>> *Subject:* Re: [dmarc-discuss] A bit quiet?
>>
>>
>> > On Oct 26, 2016, at 8:56 PM, Roland Turner via dmarc-discuss <
>> dmarc-discuss@dmarc.org> wrote:
>> >
>> > Payne, John wrote:
>> >
>> > > Yeah, but why are they showing up in _my_ DMARC reports?
>> > ...
>> > > Domain  MAIL FROM   DKIM domain SPF AuthDKIM
>> Auth   Total
>> > > akamai.com oppa.com.br oppa-com-br.20150623.gappssmtp.com Pass
>> Pass237
>> >
>> > oppa.com.br has a syntactically invalid SPF record, so it's odd that
>> it's passing at all. You didn't show which IP address the reporter saw this
>> stream coming from: were they forwarded in your environment with their DKIM
>> signatures intact?
>>
>> That was just a random example.   The IPs are all Google.  These are not
>> forwarded within my environment.
>>
>>
>> First couple from literally thousands of Google IPs:
>> IP  PTR NameSBRSCountry DMARC Fail %DMARC Fail
>> Total
>> 2607:f8b0:4003:c06::247 mail-oi0-x247.google.com (IPv6) 99.96%
>> 2,847   2,848
>> 2607:f8b0:4003:c06::245 mail-oi0-x245.google.com (IPv6) 99.96%
>> 2,792   2,793
>> 2607:f8b0:4003:c06::246 mail-oi0-x246.google.com (IPv6) 100.00%
>> 2,769   2,769
>> 2607:f8b0:4003:c06::248 mail-oi0-x248.google.com (IPv6) 99.96%
>> 2,673   2,674
>>
>>
>> Drilling into that first one and again, just taking the first couple
>> because it’s just more of the same with many different domains:
>>
>> Domain  MAIL FROM   

Re: [dmarc-discuss] A bit quiet?

[Brandon Long via dmarc-discuss]

This sounds likely to be messages from your domain that were forwarded by
Google apps, most likely mailing lists.

If the message was authenticated inbound to the mailing list, it will be
signed outbound by the domain hosting the list.

If you were p=reject or quarantine, we would rewrite the from.  It's
unfortunate that we don't rewrite while you are p=none, I'm unsure whether
we should change that or wait for arc.

As everyone knows, rewriting isn't a great experience, which is why we
haven't done it for p=none, but if it makes the reporting too annoying to
go to p=reject, we should rethink.

Also, if you're using a third party to analyse your rua reports, perhaps
they should do more to help for this case.

Would it help if we reported these as a passed by local policy, since they
would by xoar?

Brandon

On Oct 27, 2016 8:19 PM, "Roland Turner via dmarc-discuss" <
dmarc-discuss@dmarc.org> wrote:

> John,
>
>
> My apologies, I appear to have misinterpreted this completely, not sure
> what I was thinking:
>
>- DMARC reports are sent to the address specified in the DMARC record
>associated with the 5322.From address, not the source IP addresses.
>- Therefore, these reports are sent to you because the 5322.From
>header contains an akamai.com address.
>- The examples that you're citing showing a 5321.MailFrom address
>(with SPF pass) and DKIM d= domain (with DKIM pass) that are aligned with
>each other. This suggests either (a) a message sent legitimately by
>yourselves and legitimately forwarded or (b) an impersonation, also 
> legitimately
>forwarded. It is to be hoped that Google's DMARC reports
>preferentially report on DMARC-aligned DKIM passes if they're present,
>suggesting that the messages in question are passing through DKIM-breaking
>forwarding (case (a)) or lack DKIM signatures (hopefully case (b)).
>
> I'm guessing that you'd already worked this out.
>
>
> The forwarding cases are the awkward corner case for DMARC. As a domain
> owner/registrant there's probably not much that you can do about this.
> Someone like PayPal can, because of the stakes involved, stipulate that
> users (a) provide an end-address and (b) not forward it. I don't imagine
> that you're in a position to do so. ARC goes some way to helping receivers
> make better decisions, but that doesn't give you much to work with.
>
>
> Is there email sent legitimately with an @akamai.com email address that
> isn't from an Akamai employee or automated system? If so, are the stakes
> high enough that you're in a position to direct employees to avoid using
> their work email addresses for mailing lists? (This won't solve the
> problem, but may significantly reduce it.) Are you able to quantify the
> damage being done at present? (If not, stop work on this now!)
>
>
> - Roland
>
> --
> *From:* Payne, John 
> *Sent:* Friday, 28 October 2016 04:45
> *To:* Roland Turner
> *Cc:* DMARC Discussion List
> *Subject:* Re: [dmarc-discuss] A bit quiet?
>
>
> > On Oct 26, 2016, at 8:56 PM, Roland Turner via dmarc-discuss <
> dmarc-discuss@dmarc.org> wrote:
> >
> > Payne, John wrote:
> >
> > > Yeah, but why are they showing up in _my_ DMARC reports?
> > ...
> > > Domain  MAIL FROM   DKIM domain SPF AuthDKIM
> Auth   Total
> > > akamai.com oppa.com.br oppa-com-br.20150623.gappssmtp.com Pass
> Pass237
> >
> > oppa.com.br has a syntactically invalid SPF record, so it's odd that
> it's passing at all. You didn't show which IP address the reporter saw this
> stream coming from: were they forwarded in your environment with their DKIM
> signatures intact?
>
> That was just a random example.   The IPs are all Google.  These are not
> forwarded within my environment.
>
>
> First couple from literally thousands of Google IPs:
> IP  PTR NameSBRSCountry DMARC Fail %DMARC Fail
> Total
> 2607:f8b0:4003:c06::247 mail-oi0-x247.google.com (IPv6) 99.96%
> 2,847   2,848
> 2607:f8b0:4003:c06::245 mail-oi0-x245.google.com (IPv6) 99.96%
> 2,792   2,793
> 2607:f8b0:4003:c06::246 mail-oi0-x246.google.com (IPv6) 100.00%
> 2,769   2,769
> 2607:f8b0:4003:c06::248 mail-oi0-x248.google.com (IPv6) 99.96%
> 2,673   2,674
>
>
> Drilling into that first one and again, just taking the first couple
> because it’s just more of the same with many different domains:
>
> Domain  MAIL FROM   DKIM domain SPF AuthDKIM Auth
> Total
> akamai.com  kohls.com   kohls-com.20150623.gappssmtp.com
> PassPass369
> akamai.com  stickyads.tvstickyads.tvPassPass256
> akamai.com  jforce.com.tw   jforce-com-tw.20150623.gappssmtp.com
> PassPass238
> akamai.com  ziffdavis.com   ziffdavis-com.20150623.gappssmtp.com
> PassPass205
>
>
>
> There are no RUFs generated, only RUAs.
>
> As an example of why this is a problem for me… Yesterday out of 53,078
> DMARC failures, 

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

[Brandon Long via dmarc-discuss]

Actually, from the code, I'm surprised we handle a single address with !
correctly.  I'll file a bug.

Brandon

On Tue, Oct 4, 2016 at 12:21 AM, Juri Haberland via dmarc-discuss <
dmarc-discuss@dmarc.org> wrote:

> Hi,
>
> while writing a patch for OpenDMARC, I stumbled accross problems with the
> size limit in DMARC URIs that some of the big players have.
>
> Microsoft cannot cope at all with an URI like "rep...@example.org!10m" -
> you won't receive a single report.
>
> Yahoo and Google do send a report and respect the size limit - as long as
> this URI is the only one in the rua tag.
> As soon as one adds another URI (with or without size limit) to the rua
> tag, Google and Yahoo forget to strip the size limit from the URI and thus
> try to send a mail to "rep...@example.org!10m"!
>
> As OpenDMARC also had problems with the size limit in older versions, it is
> best to avoid the use of size limits for now.
>
>
>   Juri
> ___
> 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] submission via google / dmarc fail

[Brandon Long via dmarc-discuss]

Sorry, I wasn't on dmarc-discuss for some reason, looking at the archive:

A. Schulze via dmarc-discuss:

>
> I like to point to that open topic without any answer I hoped to get
> from Google
>
> simple setup:
> gmail user send with RFC5322.From *@googlemail.com via google using a
> smartphone.
> the user authenticate as *@gmail.com for submission.
> dkim signing domain: header.d=gmail.com
> spf: gmail.com
> dmarc policy for googlemail.com: quarantine
> result: dmarc fail.
>   - should gmail users no longer use RFC5322.From *@googlemail.com?
>

googlemail.com is definitely "old" and unnecessary, but it shouldn't be
broken.


>   - should gmail users using RFC5322.From *@googlemail.com also
> authenticate the submission as *@googlemail.com?
>

We've been making changes in this area for other things and may have broken
this, and given the state of change, I don't know if it's still broken or
not.  Also, creating a googlemail.com account is complicated, so it's not
easy for me to test myself.

If it doesn't work for login @gmail.com send from @googlemail.com, but does
for login @googemail.com send from @googlemail.com.  I was able to test and
show that login @googlemail.com and send from @gmail.com for my gmail.com
account works fine.

If you can reproduce an issue, please email me with the actual account
information and headers, so I can try to find logs.

Brandon


>   - or is it simply an issue that such messages are not handled
> correctly at google?
> Any clarification is welcome.
> Thanks!
>
> > Hello,
> >
> > last days I wrote to a address 
> > The answer was quarantained as the dmarc check failed.
> >
> > This ist the reply I receved:
> >
> >   Authentication-Results: mail.example.org; dmarc=fail
> > header.from=googlemail.com
> >   Authentication-Results: mail.example.org;
> > dkim=pass (2048-bit key; unprotected) header.d=gmail.com
> > header.i=@gmail.com header.b=gG3f0joi
> >   Authentication-Results: mail.example.org; spf=pass
> > smtp.mailfrom=
> > smtp.helo=mail-wi0-x234.google.com
> >   ...
> >   Received: from [...] (users.submission.client. [public.ip])
> > by smtp.googlemail.com with ESMTPSA id
> > e8sm15252097wiz.0.2015.08.16.23.40.46
> > for <$me>
> > (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256
> bits=128/128);
> > Sun, 16 Aug 2015 23:40:46 -0700 (PDT)
> >   Sender: User 
> >   From: User 
> >   X-Google-Original-From: User  gmail.com>
> >   Message-ID: <55D181EE.8 at gmail.com>
> >   User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0)
> > Gecko/20100101 Icedove/31.7.0
> >   To: ... $me
> >   ...
> >
> > So Sender and X-Google-Original-From are "@gmail.com", but From is
> > "@googlemail.com"
> > No idea if the user did something wrong or only hit a common pitfall.
> > Looks like this user may mix two similar addresses with different
> > domainparts while using them as RFC5322.From or SMTP-Auth Username.
> >
> > Maybe the google people could clarify?
> >
> > Thanks,
> > Andreas


On Sat, May 7, 2016 at 2:16 AM, A. Schulze via dmarc-discuss <
dmarc-discuss@dmarc.org> wrote:

>
>
> Am 29.04.2016 um 11:15 schrieb A. Schulze via dmarc-discuss:
>
>> I like to point to that open topic without any answer I hoped to get from
>> Google
>>
>
> nobody could clarify?
>
> 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)