Re: [dmarc-discuss] [Newbie warning] Both spf and dkim?

[Paul Rock via dmarc-discuss]

Hi there Carlos -

The main reason people say you should have both is that many customers do
things completely legitimately (like mail forwarding) that break SPF. Any
of those messages that lack DKIM will automatically fail DMARC, and
customers will wonder what the heck happened to their mail, which is why
it's advised that you should have both SPF and DKIM before moving to a
reject or quarantine policy.

On Wed, Aug 12, 2015 at 1:46 PM, 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)




-- 
PAUL ROCK
Principal Programmer/Analyst | AOL Mail
P: 703-265-5734 | C: 703-980-8380
AIM: paulsrock
22070 Broderick Dr.| Dulles, VA | 20166-9305
___
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

[Paul Rock via dmarc-discuss]

While I can't speak for everyone, in theory yes, they could impact your
reputation if those are a significant % of your traffic to us. Of course,
if they are a significant % of your traffic, you're probably not sending
much mail to us in the first place, so... *shrug*.

However, I would make the argument that companies who publish a DMARC
record with an undeliverable reporting address probably aren't paying much
attention to their mail flow. It's much more likely to impact their
reputation (if you won't take reports from me you've asked for...).

On Thu, Jul 9, 2015 at 9:33 AM, Jacob Evans via dmarc-discuss 
dmarc-discuss@dmarc.org wrote:

  Can DMARC reports hurt my reputation?  I know most ISP’s treat repeated
 NDR’s as malicious or abusive behavior.  Thoughts?



 -Jake



 Here’s a list of a few:

   dmarcrepo...@mail.cnn.com

 SMTP error from remote mail server after RCPT TO:
 dmarcrepo...@mail.cnn.com:

 host smtpvip.turner.com [157.166.228.84]: 554 5.7.1 
 dmarcrepo...@mail.cnn.com:

 Relay access denied

   dmarc-foren...@emedia.co.uk

SMTP error from remote mail server after RCPT TO:
 dmarc-foren...@emedia.co.uk:

 host aspmx.l.google.com [2607:f8b0:400d:c04::1a]:

 550-5.1.1 The email account that you tried to reach does not exist.
 Please try

 550-5.1.1 double-checking the recipient's email address for typos or

 550-5.1.1 unnecessary spaces. Learn more at

 550 5.1.1  https://support.google.com/mail/answer/6596
 c93si5552955qgd.5 - gsmtp

   dmarc_i...@service.alibaba.com

 SMTP error from remote mail server after RCPT TO:
 dmarc_i...@service.alibaba.com:

 host mx2.mail.aliyun.com [110.75.48.150]: 552 RCPT TO mailbox
 unavailable

 dma...@email4-beyond.com

 SMTP error from remote mail server after RCPT TO:
 dma...@email4-beyond.com:

 host email4-beyond.com [67.216.72.162]: 511 Host Not Authorized to
 Relay

   dmarc_...@wrtech.com

 SMTP error from remote mail server after RCPT TO:dmarc_...@wrtech.com
 :

 host mx1.emailsrvr.com [173.203.2.36]: 550 5.7.1 dmarc_...@wrtech.com
 :

 Relay access denied.



 --

 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.

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




-- 
PAUL ROCK
Principal Programmer/Analyst | AOL Mail
P: 703-265-5734 | C: 703-980-8380
AIM: paulsrock
22070 Broderick Dr.| Dulles, VA | 20166-9305
___
dmarc-discuss mailing list
dmarc-discuss@dmarc.org
http://www.dmarc.org/mailman/listinfo/dmarc-discuss

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

Re: [dmarc-discuss] Deliverability of DMARC reports

[Paul Rock via dmarc-discuss]

At AOL we see this as well, and for now we're treating it as "they're still
figuring this DMARC thing out". If it's someone we have a regular
relationship with and it's not a blip, we'll reach out and ask what's up.
If it appears to be a serious issue - a domain getting heavily abused for
example - we'll also try and reach out.

We're not currently using it as a feature in our reputation systems, so not
taking your DMARC reports isn't going to impact your reputation here at AOL
(for now). We consider it bad form, but that's about it.

The @dmarc.org (and similar) reporting addresses make us giggle, but again
we're not holding that against anyone yet.

As for DoS via DMARC - that's one of the (many) reasons we don't do
forensic reporting. I can't tell you how many times we've seen small orgs
with no or misconfigured SPF being abused by spammers with horrible lists
that generate lots of bounces. We try to catch that before it's too bad for
the small org, but we've unintentionally crushed a mail server or three
because of this. What we haven't seen yet, and I'm not really sure it's
worth the trouble for the bad guys seeing that there are soo many easier
ways to cause trouble, is someone setting up a ton of domains that all send
reports to a victim/target. Of course, now that I've said that, someone
will do it tomorrow.

On Sat, Sep 10, 2016 at 12:53 PM, John Levine via dmarc-discuss <
dmarc-discuss@dmarc.org> wrote:

> >There's a semi-related issue I'm seeing. A number of domains have used
> >addresses @dmarc.org for their aggregate reports, and some report
> >generators have not implemented cross-domain reporting authorization
> >checks. This volume pales in comparison to the volume of spam directed
> >at the same reporting address, but is anybody else seeing this and
> >thinks it's a problem?
>
> I think you're just observing the truism that no good deed goes
> unpunished.  Perhaps you could treat it as lead generation, collect
> the reports and offer to sell advice to both the people sending them
> and the ones reported on to improve their DMARC setup.
>
>
> >> Do postmasters risk bad reputation if they continue to send DMARC
> reports?
> >
> >Another question a friendly large mailbox provider could possibly answer
> >for us... Has anybody asked Spamhaus to see if this is on their radar?
>
> I'm reasonably sure it is not.
>
> >That inspires another question -- has anybody seen a real-world abuse or
> >DoS involving DMARC reporting? There's a potential there, and I believe
> >we identified it in the security considerations in RFC7489, but is there
> >any indication this is a problem that needs more attention?
>
> Unless a really gigantic provider pointed their reports at you, it
> seems unlikely.  I've been collecting reports for a dozen domains
> since 2012 and the total number of aggregate reports since I've
> started is less than 100,000, failure reports less than 60,000.
>
> R's,
> John
> ___
> dmarc-discuss mailing list
> dmarc-discuss@dmarc.org
> http://www.dmarc.org/mailman/listinfo/dmarc-discuss
>
> NOTE: Participating in this list means you agree to the DMARC Note Well
> terms (http://www.dmarc.org/note_well.html)
>



-- 
PAUL ROCK
Principal Software Engineer | AOL Mail
P: 703-265-5734 | C: 703-980-8380
AIM: paulsrock
22070 Broderick Dr.| Dulles, VA | 20166-9305
___
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?

[Paul Rock via dmarc-discuss]

I'll second what Franck has said -

Once we we figured out all of the 3rd parties we needed to talk to,
virtually everyone was happy to work with us to find a solution. The
biggest problem we've had, by far, was internals who couldn't be bothered
to figure out how mail works, and then suddenly their big email push
explodes and it's all MY fault.

On Mon, Sep 26, 2016 at 4:34 PM, Franck Martin via dmarc-discuss <
dmarc-discuss@dmarc.org> wrote:

> We do enforce inbound policy, in fact this has been very useful, when you
> send to yourself a copy of the failure reports, It allows you to find
> problems with your email streams before they become real problems (as well
> as all the details helping you to fix them).
>
> cf: https://github.com/linkedin/lafayette/wiki/Screenshots
>
> I had to put one or two companies in a local policy exception, but they
> were emailing only our employees, not the whole world.
>
> Many third parties can abide to your DMARC policy, but you need to spell
> it out what you want them to do, as many do not understand what DMARC is.
>
> I have used that FAQ entry a lot with all 3rd parties: https://dmarc.org/
> wiki/FAQ#My_organization_uses_third-parties_senders.2C_how_
> can_I_get_them_DMARC_compliant.3F
>
> On Mon, Sep 26, 2016 at 9:03 AM, Payne, John  wrote:
>
>>
>> On Sep 22, 2016, at 10:34 PM, Franck Martin  wrote:
>>
>> https://engineering.linkedin.com/email/dmarc-new-tool-detect
>> -genuine-emails
>> 
>> https://engineering.linkedin.com/email/dmarc-moving-monitor-reject-mode
>> 
>>
>> google.com
>> 
>> is p=quarantine
>> yahoo-inc.com
>> 
>> is p=reject
>> microsoft.com
>> 
>> is p=quarantine
>> paypal-inc.com
>> 
>> is p=reject
>>
>> You will find other resources at dmarc.org
>>
>>
>> google.com is p=reject FWIW
>>
>> I’m interested in how these companies got to that point.  What
>> workarounds are they relying on if any?
>> Are they enforcing DMARC policies inbound?
>>
>>
>> As for the Gmail question, I think it is linked to the release of ARC.
>>
>>
>> So I’ve heard.  I hope that turns out to be useful for the rest of us :)
>>
>>
>> On Mon, Sep 19, 2016 at 12:06 PM, Payne, John via dmarc-discuss <
>> dmarc-discuss@dmarc.org> wrote:
>>
>>>
>>> > On Oct 22, 2015, at 3:43 PM, Payne, John  wrote:
>>> >
>>> >
>>> >> On Oct 22, 2015, at 3:36 PM, Andrew Beverley via dmarc-discuss <
>>> dmarc-discuss@dmarc.org> 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
>>> >
>>> > I’m hoping that it encourages the mailing list folk who have been
>>> reluctant to become DMARC safe to reconsider, whether thats ARC or wrapping.
>>> > As an enterprise hoping to go p=reject, this is potentially a big deal
>>> for me :)
>>>
>>>
>>> I’m not exactly in the loop, but besides this article almost a year ago,
>>> I haven’t seen anything else about gmail going p=reject… and it’s now 3
>>> months past the advertised 

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

[Paul Rock via dmarc-discuss]

We're mainly interested in the data for anti-phishing purposes - If they're
trying to phish us, they're likely trying to phish others too.

On Fri, Sep 30, 2016 at 12:35 PM, Terry Zink via dmarc-discuss <
dmarc-discuss@dmarc.org> wrote:

> Could this be simplified further:
>
>
>
> a01.com IN TXT "v=spf1 -all"
>
> _dmarc.a01.com IN TXT "v=DMARC1\; p=reject"
>
>
>
> If the domain never sends email, I don’t particularly care to receive
> reports. I guess the argument is that it may be interesting to see who is
> sending email as this parked domain.
>
>
>
> --Terry
>
>
>
> *From:* dmarc-discuss [mailto:dmarc-discuss-boun...@dmarc.org] *On Behalf
> Of *Paul Rock via dmarc-discuss
> *Sent:* Friday, September 30, 2016 7:22 AM
> *To:* mi...@basejp.com
> *Cc:* dmarc-discuss <dmarc-discuss@dmarc.org>
> *Subject:* Re: [dmarc-discuss] DMARC where mail is never sent
>
>
>
> Yes, mainly for brand/domain protection. We see spammers co-opt domains
> all the time that are widely recognized but not normally used for mail.
> I've told people in the past to do this for domains that they own that
> should never send mail, especially lookalike or spoof domains that you own
> for brand protection. See a0l.com
> <https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fa0l.com=01%7C01%7Ctzink%40exchange.microsoft.com%7C04e6616edc4b46d5719408d3e93ddb01%7C72f988bf86f141af91ab2d7cd011db47%7C1=uzKQjuaT%2BO%2FtTtBSFjVH7%2ByJzDjZpZz2NZodq4AVIn0%3D=0>
> for example:
>
>
>
> a0l.com
> <https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fa0l.com=01%7C01%7Ctzink%40exchange.microsoft.com%7C04e6616edc4b46d5719408d3e93ddb01%7C72f988bf86f141af91ab2d7cd011db47%7C1=uzKQjuaT%2BO%2FtTtBSFjVH7%2ByJzDjZpZz2NZodq4AVIn0%3D=0>.
>3578IN  TXT "v=spf1 -all"
>
> _dmarc.a0l.com
> <https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fdmarc.a0l.com=01%7C01%7Ctzink%40exchange.microsoft.com%7C04e6616edc4b46d5719408d3e93ddb01%7C72f988bf86f141af91ab2d7cd011db47%7C1=f5MNVkLqnlj0Lw5pDme2my1yKikswUtndtyD5M6A4vY%3D=0>.
> 3559IN  TXT "v=DMARC1\; p=reject\; fo=1\; rua=mailto:
> a...@rua.agari.com\; ruf=mailto:a...@ruf.agari.com;
>
>
>
>
>
> On Fri, Sep 30, 2016 at 9:55 AM, Mitchell Kuch via dmarc-discuss <
> dmarc-discuss@dmarc.org> wrote:
>
> Hello -
>
> Does it make sense to publish a DMARC record to signal that a host
> should never send email? Can said record be published without an
> accompanying DKIM record?
>
>  Thanks,
>  - - Mitchell
>
>
> v=spf1 -all
> v=DMARC1; p=reject; rua=mailto:mailreports@test.example;
> ruf=mailto:mailreports@test.example; fo=0; adkim=s; aspf=s; pct=100;
> rf=afrf; ri=1; sp=reject
> ___
> dmarc-discuss mailing list
> dmarc-discuss@dmarc.org
> http://www.dmarc.org/mailman/listinfo/dmarc-discuss
> <https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.dmarc.org%2Fmailman%2Flistinfo%2Fdmarc-discuss=01%7C01%7Ctzink%40exchange.microsoft.com%7C04e6616edc4b46d5719408d3e93ddb01%7C72f988bf86f141af91ab2d7cd011db47%7C1=fN3hNZzOvLo1qZlE%2FjWXiWpQaRsjzBvEN8gPAFKHDq4%3D=0>
>
> NOTE: Participating in this list means you agree to the DMARC Note Well
> terms (http://www.dmarc.org/note_well.html
> <https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.dmarc.org%2Fnote_well.html=01%7C01%7Ctzink%40exchange.microsoft.com%7C04e6616edc4b46d5719408d3e93ddb01%7C72f988bf86f141af91ab2d7cd011db47%7C1=EphsaQa7%2F7jucdMmdwkGt9tLp8yoCnM7%2BrBToGrT1hU%3D=0>
> )
>
>
>
>
>
> --
>
>
> *PAUL ROCK *
> *Principal Software Engineer | AOL Mail *P: 703-265-5734 | C: 703-980-8380
> AIM: paulsrock
> 22070 Broderick Dr.| Dulles, VA | 20166-9305
>
> ___
> 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)
>



-- 
PAUL ROCK
Principal Software Engineer | AOL Mail
P: 703-265-5734 | C: 703-980-8380
AIM: paulsrock
22070 Broderick Dr.| Dulles, VA | 20166-9305
___
dmarc-discuss mailing list
dmarc-discuss@dmarc.org
http://www.dmarc.org/mailman/listinfo/dmarc-discuss

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

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

[Paul Rock via dmarc-discuss]

Yes, mainly for brand/domain protection. We see spammers co-opt domains all
the time that are widely recognized but not normally used for mail. I've
told people in the past to do this for domains that they own that should
never send mail, especially lookalike or spoof domains that you own for
brand protection. See a0l.com for example:

a0l.com.3578IN  TXT "v=spf1 -all"
_dmarc.a0l.com. 3559IN  TXT "v=DMARC1\; p=reject\;
fo=1\; rua=mailto:a...@rua.agari.com\; ruf=mailto:a...@ruf.agari.com;


On Fri, Sep 30, 2016 at 9:55 AM, Mitchell Kuch via dmarc-discuss <
dmarc-discuss@dmarc.org> wrote:

> Hello -
>
> Does it make sense to publish a DMARC record to signal that a host
> should never send email? Can said record be published without an
> accompanying DKIM record?
>
>  Thanks,
>  - - Mitchell
>
>
> v=spf1 -all
> v=DMARC1; p=reject; rua=mailto:mailreports@test.example;
> ruf=mailto:mailreports@test.example; fo=0; adkim=s; aspf=s; pct=100;
> rf=afrf; ri=1; sp=reject
> ___
> 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)
>



-- 
PAUL ROCK
Principal Software Engineer | AOL Mail
P: 703-265-5734 | C: 703-980-8380
AIM: paulsrock
22070 Broderick Dr.| Dulles, VA | 20166-9305
___
dmarc-discuss mailing list
dmarc-discuss@dmarc.org
http://www.dmarc.org/mailman/listinfo/dmarc-discuss

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

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

[Paul Rock via dmarc-discuss]

Sorry for not saying so earlier, but we're looking into the multiple to
thing. We'll roll out a fix asap.

On Thu, Oct 13, 2016 at 3:30 AM, Alessandro Vesely via dmarc-discuss <
dmarc-discuss@dmarc.org> wrote:

> On Wed 12/Oct/2016 21:38:45 +0200 Juri Haberland via dmarc-discuss wrote:
>
>> On 12.10.2016 12:17, Steven M Jones via dmarc-discuss wrote:
>>
>>> On 10/12/16 01:32, Juri Haberland via dmarc-discuss wrote:
>>>
>>
>> Btw: Did anyone notice that AOL sends DMARC reports with two To: headers?

>>>
>>> Looking at the last few reports I received from them for this domain, I
>>> only see one 5322.To header. But the most recent report was
>>> mid-September. Anybody else out there seeing two? It could make tracking
>>> down a bug much easier for them.
>>>
>>
>> My last report is half a year old, but has two headers, too:
>>
>> From: abuse_dm...@abuse.aol.com
>> To: r...@dmarc.sapienti-sat.org
>> To: pboza...@ag.dmarcian.com
>>
>> So it seems, AOL is putting every rua URI into a seperate To: header...
>>
>
> I'm surprised no AOL people spoke, so I CC this to the address I found in
> their report_metadata/email field.
>
> Instead, we could add an extra_contact_info entry pointing to this list,
> no?
>
> Ale
>
> ___
> 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)
>



-- 
PAUL ROCK
Principal Software Engineer | AOL Mail
P: 703-265-5734 | C: 703-980-8380
AIM: paulsrock
22070 Broderick Dr.| Dulles, VA | 20166-9305
___
dmarc-discuss mailing list
dmarc-discuss@dmarc.org
http://www.dmarc.org/mailman/listinfo/dmarc-discuss

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

Re: [dmarc-discuss] FBL via DMARC?

[Paul Rock via dmarc-discuss]

At AOL we're doing this with a confirmation popup in clients we control and
then sending a unsubscribe mail on behalf of the user when we find
unsubscribe mailto links, and I know that some 3rd party clients also have
started to implement unsubscribe logic (iOS 10 does so for example). I also
know (and I think I'm allowed to say) we've been working on code to do the
one click URL based unsubscribe as well.

On Tue, Nov 29, 2016 at 8:51 PM, John R Levine via dmarc-discuss <
dmarc-discuss@dmarc.org> wrote:

> What would be great is if this RFC could have some language discussing
>> having a confirmation dialog to prevent these accidental mistakes from
>> happening.
>>
>
> It does.  It says that the whole point of this draft is to have a
> non-interactive unsubscribe that mail systems can do in the background when
> people report mail as spam.
>
> Mailers may not like it, but it's what recipient systems want, and what
> they've told me they're going to do.
>
>
> 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)
>



-- 
PAUL ROCK
Principal Software Engineer | AOL Mail
P: 703-265-5734 | C: 703-980-8380
AIM: paulsrock
22070 Broderick Dr.| Dulles, VA | 20166-9305
___
dmarc-discuss mailing list
dmarc-discuss@dmarc.org
http://www.dmarc.org/mailman/listinfo/dmarc-discuss

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

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

[Paul Rock via dmarc-discuss]

This is a pretty common practice for domains that people own for brand
protection as well - a0l.com has a -all SPF, p=reject DMARC policy, and no
MX.

On Thu, Oct 12, 2017 at 1:22 AM, Pete Holzmann via dmarc-discuss <
dmarc-discuss@dmarc.org> wrote:

> Awesome! Thank you SO much :)
>
> On 12 Oct 2017 John Levine said...
>
> >If you want no mail sent or received by ds.org (as opposed
> >to any other domains you host) it is just fine to say
> >that.
>
> ___
> 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)
>



-- 
PAUL ROCK
*Sr Software Dev Engineer* | AOL Mail
P: 703-265-5734 | C: 703-980-8380
AIM: paulsrock
22070 Broderick Dr.| Dulles, VA | 20166-9305
___
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

[Paul Rock via dmarc-discuss]

1) Yes, via two methods - The first is mailbox aggregation (why setup
forwarding when I can just read the mailbox for you?) which is currently
supported by a number of email providers. The second is via Authenticated
Received Chain (ARC - see http://arc-spec.org/). Also currently supported
by a number of email providers.
2) Yes, but because it requires potentially significant user and provider
work, it's not really seen as a preferred solution. It also doesn't solve
many other issues that forwarding (and things like Lists) have with DMARC.
ARC should be able to solve these problems without requiring user
work/effort - it will however require provider effort, but most of the
major providers and several large FOSS mail packages/libraries already have
implemented or have committed to implementing ARC. See http://arc-spec.org/
for the current state of things.

On Mon, May 21, 2018 at 11:29 AM, Pete Holzmann via dmarc-discuss <
dmarc-discuss@dmarc.org> wrote:

> I'm seeing a growing number of bounce-back errors from major players who
> have DMARC fully implemented.
>
> I have some observations, questions and a suggestion.
>
> Blessings,
> Pete
>
> *OBSERVATIONS*
>
> There's a pattern here that I suspect is only going to grow:
>
> * User R with SomeCo creates an email filter rule to auto-forward some
> subset of incoming emails to their smart phone or other alternate mailbox
> (gmail, apple, etc)
>
> * From 'R's perspective, they simply want those emails to show up in their
> "other inbox"
>
> * From Google/Apple/etc perspective, those emails get the full treatment
> for:
> - SPF/DKIM/DMARC validity
> - Anti-spam filtering
> - Etc.
>
> The result (with varying details):
>
> a) Originator "O" of the email may get a DMARC bounceback (see example
> below) indicating that gmail (or whoever) would not accept the message.
> b) User "R" with the forwarding rule may find messages not showing up on
> their phone.
> c) Google/Apple/etc may start treating SomeCo as a source of spam
>
> ...and the hard part: from Originator and User perspective, everybody's
> doing what is "normal" but the email systems are causing grief. Only an
> expert examining headers and server logs can get a clue about what is
> happening.
>
> In a perfect world all software will perfectly implement DMARC. In the
> meantime, users get frustrated and email gets blocked.
>
> *QUESTIONS:*
> 1) Is anyone working to solve these issues?
> 2) Has there been consideration of a forwarding token that could validate
> all such emails?
>
> *SUGGESTION: *
> a) Since user+al...@dom.ain is a valid alias for u...@dom.ain ...
> b) Why not create a standard for personal forwarding authentication
> tokens? I.e.
>* A typical mechanism is used to create token asd!_4521Zxy
>* asd!_4521Zxy is stored as PrivateForwardToken in gmail box or
> ???
>* User forwards their email to user+asd!_4521...@gmail.com
> instead of
>   u...@gmail.com
>* Google auto-approves all such email as if it were internal
> rather than
>   externally sourced.
>
> [Probably needs modifying so such messages are rapidly recognized during
> transport... but I want to make sure end users can easily implement this on
> ANY email client, ANY email service, without help.]
>
>
> *EXAMPLE*
>
> I sent email to a friend. I received this bounceback. I was surprised to
> hear that my friend received the message... until on questioning he
> realized he also was auto-copying to a gmail box.
>
>
> Sorry. Your message could not be delivered to:
>
> gmail.com
>  DATA
>  Received: 5.7.1 Unauthenticated email from icta.net is
> not accepted due to domain's
>5.7.1 DMARC policy. Please contact
> the administrator of icta.net domain if
>5.7.1 this was a legitimate mail.
> Please visit
>5.7.1  https://support.google.com/
> mail/answer/2451690 to learn about the
>5.7.1 DMARC initiative.
> s4-v6si8436056ita.127 - gsmtp
>
> [end]
>
>
> ___
> 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)
>



-- 
PAUL ROCK
*Sr Software Dev Engineer* | AOL Mail
P: 703-265-5734 | C: 703-980-8380
AIM: paulsrock
22070 Broderick Dr.| Dulles, VA | 20166-9305
___
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)