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

[Al Iverson via dmarc-discuss]

Thanks! And a valid point. :)

Al

On Mon, Mar 9, 2020 at 3:39 PM Kurt Andersen (DMARC)
 wrote:
>
> If the signature is not broken, then having DKIM pass is sufficient for a 
> DMARC pass (per the spec). Whether Exchange evaluates it correctly or not is 
> a different question :-)
>
> --Kurt
>
> On Mon, Mar 9, 2020 at 1:33 PM Al Iverson via dmarc-discuss 
>  wrote:
>>
>> Dumb question time. In that scenario, if mail is forwarded with the
>> DKIM signature intact, would that be good enough to still pass DMARC?
>> Or will it fail because SPF now fails?
>>
>> Al
>>
>> On Mon, Mar 9, 2020 at 2:25 PM Ivan Kovachev via dmarc-discuss
>>  wrote:
>> >
>> > If only I could push them.
>> >
>> > On Mon, Mar 9, 2020, 18:32 Kurt Andersen  wrote:
>> >>
>> >> This is not a topic for the DMARC protocol discussion list. You should 
>> >> probably be directing the inquiry to your Exchange support channel - and 
>> >> pushing Barracuda to implement ARC (RFC8617) too :-)
>> >>
>> >> Cheers,
>> >>   Kurt Andersen
>> >>
>> >> On Mon, Mar 9, 2020 at 11:20 AM Ivan Kovachev via dmarc-discuss 
>> >>  wrote:
>> >>>
>> >>> Hello, It looks like Office 365 with a gateway in front such as 
>> >>> Barracuda or another gateway, still does DMARC validation inbound, and 
>> >>> quarantines any emails that fail DMARC validation.
>> >>>
>> >>> Should this not be the case since the MX of the receiving domain is that 
>> >>> of the Barracuda or whatever other gateway is used?
>> >>>
>> >>> DMARC validation passes at Barracuda, but then Barracuda makes changes 
>> >>> to the email which invalidates DKIM/DMARC and Office 365 quarantines 
>> >>> them, even though the email initially passed DMARC and was not 
>> >>> considered as SPAM at all.
>> >>>
>> >>> How can DMARC validation be turned off or disabled at Office 365 for the 
>> >>> above scenario?
>> >>>
>> >>>
>> >>>
>> >>> ___
>> >>> dmarc-discuss mailing list
>> >>> dmarc-discuss@dmarc.org
>> >>> http://www.dmarc.org/mailman/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 // wombatmail // chicago
>> dns tools are cool! https://xnnd.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)



-- 
al iverson // wombatmail // chicago
dns tools are cool! https://xnnd.com
___
dmarc-discuss mailing list
dmarc-discuss@dmarc.org
http://www.dmarc.org/mailman/listinfo/dmarc-discuss

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

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

[Al Iverson via dmarc-discuss]

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

Al

On Mon, Mar 9, 2020 at 2:25 PM Ivan Kovachev via dmarc-discuss
 wrote:
>
> If only I could push them.
>
> On Mon, Mar 9, 2020, 18:32 Kurt Andersen  wrote:
>>
>> This is not a topic for the DMARC protocol discussion list. You should 
>> probably be directing the inquiry to your Exchange support channel - and 
>> pushing Barracuda to implement ARC (RFC8617) too :-)
>>
>> Cheers,
>>   Kurt Andersen
>>
>> On Mon, Mar 9, 2020 at 11:20 AM Ivan Kovachev via dmarc-discuss 
>>  wrote:
>>>
>>> Hello, It looks like Office 365 with a gateway in front such as Barracuda 
>>> or another gateway, still does DMARC validation inbound, and quarantines 
>>> any emails that fail DMARC validation.
>>>
>>> Should this not be the case since the MX of the receiving domain is that of 
>>> the Barracuda or whatever other gateway is used?
>>>
>>> DMARC validation passes at Barracuda, but then Barracuda makes changes to 
>>> the email which invalidates DKIM/DMARC and Office 365 quarantines them, 
>>> even though the email initially passed DMARC and was not considered as SPAM 
>>> at all.
>>>
>>> How can DMARC validation be turned off or disabled at Office 365 for the 
>>> above scenario?
>>>
>>>
>>>
>>> ___
>>> dmarc-discuss mailing list
>>> dmarc-discuss@dmarc.org
>>> http://www.dmarc.org/mailman/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 // wombatmail // chicago
dns tools are cool! https://xnnd.com
___
dmarc-discuss mailing list
dmarc-discuss@dmarc.org
http://www.dmarc.org/mailman/listinfo/dmarc-discuss

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

Re: [dmarc-discuss] Testing DMARC

[Al Iverson via dmarc-discuss]

In fact, I've gone and whipped something up:

https://xnnd.com/dmarcbounce.cgi

Please don't use it for evil. I may yank it or rate limit it later.

Suggestion of a domain to try to get a positive result: mail.ru

Feedback welcome.

Cheers,
Al Iverson

On Tue, Jan 7, 2020 at 6:22 PM Al Iverson  wrote:
>
> It'd be easy enough to create a web tool to allow for this. Any
> opinions about how we'd prevent it from being misused to annoy people?
> I do see potential value in offering this.
>
> SWAKS, for example, is very easy to configure. Gerben, with your
> permission, I could set up a one off demo that would attempt to send a
> small number of emails to you with forged from addresses.
>
> To read more about SWAKS, go here: https://www.jetmore.org/john/code/swaks/
>
> I use SWAKS internally at Salesforce to confirm mail server allowed
> domain relay entries pretty much every day.
>
> Cheers,
> Al Iverson
>
> On Tue, Jan 7, 2020 at 6:18 PM Patrick Peterson via dmarc-discuss
>  wrote:
> >
> > You can use the command line (if comfortable) to spoof an email from a 
> > domain that has p=reject by sending it to your address (eg 
> > gerben.wie...@rna.nl). You can use From: u...@agari.com (p=reject) if you 
> > like or any other domain with p=reject to spoof an email to your mail 
> > server. (eg chase.com). The spoofed email will fail SPF and DKIM and you 
> > should not receive a copy of the message in your inbox and your gateway 
> > that enforces DMARC should log or report the message was rejected.
> >
> >
> >
> > Here’s a site that specifies how to use command line to spoof email
> >
> > https://dougvitale.wordpress.com/2011/12/31/send-spoofed-emails-with-telnet/
> >
> >
> >
> >
> >
> > If you are not comfortable with command line there are online tools to 
> > spoof email. I’ve never used them so am hesitant to recommend… I’ve 
> > included two below from quick internet searches – but I cannot tell you how 
> > well they work. They are top 5 search engine results so I assume they are 
> > safe and reliable enough. Use at your own risk though if you aren’t 
> > comfortable with the command line.
> >
> > https://emkei.cz/
> >
> >
> >
> > https://www.spoofbox.com/en/app/spoof-email
> >
> >
> >
> > pat
> >
> >
> >
> > From: dmarc-discuss  on behalf of 
> > "dmarc-discuss@dmarc.org" 
> > Reply-To: Gerben Wierda 
> > Date: Tuesday, January 7, 2020 at 1:20 PM
> > To: Ken O'Driscoll 
> > Cc: "dmarc-discuss@dmarc.org" 
> > Subject: Re: [dmarc-discuss] Testing DMARC
> >
> >
> >
> > Certainly, for received mail I can even just look in the headers. I am 
> > using rspamd as part of the mail setup, so maybe I can do something with 
> > rspamd logging.
> >
> >
> >
> > But the question is about reliably triggering a test where the mail server 
> > must reject. So reliably triggering so I can look at the logs to see what 
> > happens.
> >
> >
> >
> > E.g. a service that sends me a mail message but purposely from an IP that 
> > is not in the SPF record and/or a DKIM signature that is wrong and/or a 
> > DMARC situation where spf and skim do not match up. Something spammers 
> > would do.
> >
> >
> >
> > G
> >
> >
> >
> > On 7 Jan 2020, at 19:15, Ken O'Driscoll via dmarc-discuss 
> >  wrote:
> >
> >
> >
> > On Tue, 2020-01-07 at 17:04 +0100, Gerben Wierda via dmarc-discuss wrote:
> >
> > But I would like to see if a message that comes from outside and that
> > should be blocked because the owner of the domain has a policy p=reject.
> > So, some sort of tester that is able to make me test how I react on
> > incoming mail I should reject. Does something like that exist?
> >
> >
> > Perhaps I misunderstand, but wouldn't your inbound email server logs tell
> > you how DMARC is evaluated for inbound emails from domains which you do not
> > control?
> >
> > Ken.
> >
> > ___
> > dmarc-discuss mailing list
> > dmarc-discuss@dmarc.org
> > http://www.dmarc.org/mailman/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 // wombatmail // chicago
> http://www.aliverson.com
> http://www.spamresource.com



-- 
al iverson // wombatmail // chicago
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)

Re: [dmarc-discuss] Testing DMARC

[Al Iverson via dmarc-discuss]

It'd be easy enough to create a web tool to allow for this. Any
opinions about how we'd prevent it from being misused to annoy people?
I do see potential value in offering this.

SWAKS, for example, is very easy to configure. Gerben, with your
permission, I could set up a one off demo that would attempt to send a
small number of emails to you with forged from addresses.

To read more about SWAKS, go here: https://www.jetmore.org/john/code/swaks/

I use SWAKS internally at Salesforce to confirm mail server allowed
domain relay entries pretty much every day.

Cheers,
Al Iverson

On Tue, Jan 7, 2020 at 6:18 PM Patrick Peterson via dmarc-discuss
 wrote:
>
> You can use the command line (if comfortable) to spoof an email from a domain 
> that has p=reject by sending it to your address (eg gerben.wie...@rna.nl). 
> You can use From: u...@agari.com (p=reject) if you like or any other domain 
> with p=reject to spoof an email to your mail server. (eg chase.com). The 
> spoofed email will fail SPF and DKIM and you should not receive a copy of the 
> message in your inbox and your gateway that enforces DMARC should log or 
> report the message was rejected.
>
>
>
> Here’s a site that specifies how to use command line to spoof email
>
> https://dougvitale.wordpress.com/2011/12/31/send-spoofed-emails-with-telnet/
>
>
>
>
>
> If you are not comfortable with command line there are online tools to spoof 
> email. I’ve never used them so am hesitant to recommend… I’ve included two 
> below from quick internet searches – but I cannot tell you how well they 
> work. They are top 5 search engine results so I assume they are safe and 
> reliable enough. Use at your own risk though if you aren’t comfortable with 
> the command line.
>
> https://emkei.cz/
>
>
>
> https://www.spoofbox.com/en/app/spoof-email
>
>
>
> pat
>
>
>
> From: dmarc-discuss  on behalf of 
> "dmarc-discuss@dmarc.org" 
> Reply-To: Gerben Wierda 
> Date: Tuesday, January 7, 2020 at 1:20 PM
> To: Ken O'Driscoll 
> Cc: "dmarc-discuss@dmarc.org" 
> Subject: Re: [dmarc-discuss] Testing DMARC
>
>
>
> Certainly, for received mail I can even just look in the headers. I am using 
> rspamd as part of the mail setup, so maybe I can do something with rspamd 
> logging.
>
>
>
> But the question is about reliably triggering a test where the mail server 
> must reject. So reliably triggering so I can look at the logs to see what 
> happens.
>
>
>
> E.g. a service that sends me a mail message but purposely from an IP that is 
> not in the SPF record and/or a DKIM signature that is wrong and/or a DMARC 
> situation where spf and skim do not match up. Something spammers would do.
>
>
>
> G
>
>
>
> On 7 Jan 2020, at 19:15, Ken O'Driscoll via dmarc-discuss 
>  wrote:
>
>
>
> On Tue, 2020-01-07 at 17:04 +0100, Gerben Wierda via dmarc-discuss wrote:
>
> But I would like to see if a message that comes from outside and that
> should be blocked because the owner of the domain has a policy p=reject.
> So, some sort of tester that is able to make me test how I react on
> incoming mail I should reject. Does something like that exist?
>
>
> Perhaps I misunderstand, but wouldn't your inbound email server logs tell
> you how DMARC is evaluated for inbound emails from domains which you do not
> control?
>
> Ken.
>
> ___
> dmarc-discuss mailing list
> dmarc-discuss@dmarc.org
> http://www.dmarc.org/mailman/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 // wombatmail // chicago
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)

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

[Al Iverson via dmarc-discuss]

On Mon, Oct 15, 2018 at 5:44 AM Alessandro Vesely via dmarc-discuss
 wrote:

> The best path, IMHO, would be to accept that list messages are sent from the
> list, since lists add their mark to the content.

That is pretty much the rough consensus today -- there's lots of that
out in the wild, growing MLM support, Google Groups and Yahoo Groups
do this, etc.

I'd love to see it standardized and recommended more officially but I
foresee a lot of pushback from some people who don't like this, which
I kind of don't have the energy to fight. Maybe we just need to do
like was done with DMARC-- I get the impression that the DMARC design
process was driven by people tiring of fighting over ADSP, so the ones
actually interested in it split off and worked it out amongst
themselves, to get some measure of stability and a group's consensus
before going public.

Cheers,
Al


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

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

[Al Iverson via dmarc-discuss]

On Sat, Oct 13, 2018 at 9:44 PM John Levine  wrote:
>
> In article 
>  you 
> write:
> >Rewriting the from address to something that fails -- and thus is
> >potentially going to fail delivery at any ISP that checks to see if
> >the from address is valid -- seems crappy to me.
>
> Sorry, I don't understand what point you're making here.  Where do you
> see something that fails?

OK, you own a dot fail domain, get it. Ha ha, you got me. Don't blame
me for thinking an invalid-looking domain was invalid. Keep in mind
that in one of our prior arguments over header rewriting, you did
actually suggest changing the domain to .domain.INVALID.

I'd still say it's gauche, ultimately pushing the mail reply somewhere
other than to the mailing list or to the owner. If you've addressed
that, too, great, but it doesn't feel easy or scalable.

Regards,
Al

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

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

[Al Iverson via dmarc-discuss]

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

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



-- 
al iverson // 312-725-0130 // miami
http://www.aliverson.com
http://www.spamresource.com
___
dmarc-discuss mailing list
dmarc-discuss@dmarc.org
http://www.dmarc.org/mailman/listinfo/dmarc-discuss

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

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

[Al Iverson via dmarc-discuss]

On Tue, Oct 9, 2018 at 7:00 PM John Levine via dmarc-discuss
 wrote:
>
> In article <24dd5bc1-ca89-473c-9d11-cb712504c...@akamai.com> you write:
> >p=none -> “we’re trying to figure out if we’re going to be able to go to 
> >p=quarantine”
> >
> >If you treat quarantine differently than none, you’re sending me misleading 
> >data in the reports you send (if of course
> >you send reports) - or your downstream recipients send.
>
> Sorry, but that is just wrong.  I publish p=none because that is my
> policy.

It's not wrong from my perspective. It's exactly what I see in
practice from ISPs and companies. What John Payne is sharing is
literally what's been running through my head over the past couple of
months.

> That's what the spec says, that's what it means.

I think it's reasonable to discuss how most people are actually doing
with DMARC.

Al

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

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

[Al Iverson via dmarc-discuss]

I agree that special casing "p=" (versus not special casing
"p=none") is something people should do, and in my personal little
mailing list manager, I've updated it to do that, and in my day job's
email forwarding functionality, we're adding it there as well. I think
that a lot of us assumed otherwise at first though, and it's kind of
new territory. It's something I really only came to realize myself a
few months ago. Be patient, tell people about it when you see it, and
keep nudging. It takes a while for people to figure things out.

Maybe I can squeeze a blog post out of this -- and it might be good
for others to do the same.

I do personally suggest against using pct=0 anywhere in any of this
equation, though. Like mentioned, somebody's going to miss the
percentage part being zero and end up acting as it if were set to 100.

Cheers,
Al Iverson

On Tue, Oct 9, 2018 at 1:28 PM Payne, John via dmarc-discuss
 wrote:
>
>
>
> > On Oct 9, 2018, at 10:59 AM, Jonathan Kamens via dmarc-discuss 
> >  wrote:
> >
> > As I'm sure the folks on this list are aware, apparently some ESPs and 
> > software maintainers have chosen to behave differently when forwarding 
> > emails (most notably to mailing lists) depending on whether the sender's 
> > domain DMARC policy is nonexistent or p=none, vs. p=quarantine or p=reject.
> >
> > In particular, the ones that I know about are Google Groups and GNU 
> > Mailman, both of which have decided to rewrite From: lines when they see 
> > p=quarantine or p=reject but leave them intact when they see no DMARC 
> > policy or a policy with p=none.
> >
> > I find this bewildering and frustrating both for domains attempting to roll 
> > out DMARC and for the administrators of mail servers attempting to enforce 
> > it on incoming emails.
> >
> > From the outbound email point of view, what good does it do to get 
> > aggregate reports telling you messages forwarded through mailing lists 
> > weren't DMARC compliant when you can't do anything about it and when 
> > messages sent through those same mailing lists will magically become 
> > compliant when you switch from p=none to p=quarantine? This is especially 
> > true since you can't actually know that those messages are going to 
> > magically become compliant, because you can't know which mailing list 
> > platforms play this game.
> >
> > From the inbound email point of view, having just deployed the current beta 
> > release of OpenDMARC on my personal (not Quantopian's) mail server 
> > (Incidentally, an aside: is anybody actually maintaining OpenDMARC? There 
> > are multiple significant bugs in it that have been reported with patches on 
> > Github and the maintainers there have been radio silent for months), I am 
> > carefully monitoring the logs, both to confirm that it is behaving properly 
> > and so that I can detect and report any problems to the OpenDMARC 
> > maintainers (I've already submitted several bug reports and patches). 
> > Several times a week I get a "domain fail" log message from OpenDMARC and I 
> > have to investigate it, only to discover that the only reason for the 
> > failure is because someone on my server received a message through a 
> > mailing list and the sender domain's DMARC policy is p=none.
> >
> > I see people behaving badly here in both directions. In my opinion, servers 
> > that do message forwarding should rewrite headers for DMARC compliance 
> > whenever there is a DMARC policy, not just when the policy is p=quarantine 
> > or p=reject. And on the other end, given that the servers that do 
> > forwarding aren't behaving that way, nobody should be using p=none in their 
> > policy; they should instead use p=quarantine; pct=0 to force their headers 
> > to be rewritten during forwarding.
> >
> > Am I missing something here?
>
> Thats exactly the situation I’m in.I believe that p= should 
> trigger “special handling” if there is any to be triggered.  p=none is 
> semantically different from the record not existing, but it’s being treated 
> the same.
>
> Of course, p=quarantine; pct=0 does run the risk of receivers not obeying the 
> pct… which I think there’s at least 1 out there….
>
> ___
> dmarc-discuss mailing list
> dmarc-discuss@dmarc.org
> http://www.dmarc.org/mailman/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)

Re: [dmarc-discuss] Spam from LinkedIn

[Al Iverson via dmarc-discuss]

Annoying for sure, but what does this have to do with implementing
DMARC? This seems off topic.
On Tue, Oct 2, 2018 at 6:47 AM Marina Veneka via dmarc-discuss
 wrote:
>
> Message source: Received: from 
> HE1EUR02HT135.eop-EUR02.prod.protection.outlook.com
>  (2603:10a6:208:1::33) by AM0PR0202MB3523.eurprd02.prod.outlook.com with HTTPS
>  via AM0PR0202CA0020.EURPRD02.PROD.OUTLOOK.COM; Mon, 1 Oct 2018 15:30:40 +
> Received: from HE1EUR02FT037.eop-EUR02.prod.protection.outlook.com
>  (10.152.10.57) by HE1EUR02HT135.eop-EUR02.prod.protection.outlook.com
>  (10.152.11.79) with Microsoft SMTP Server (version=TLS1_2,
>  cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.20.1185.13; Mon, 1
>  Oct 2018 15:30:40 +
> Authentication-Results: spf=none (sender IP is 85.214.229.191)
>  smtp.mailfrom=coolnclassy.com; hotmail.co.uk; dkim=none (message not signed)
>  header.d=none;hotmail.co.uk; dmarc=none action=none
>  header.from=coolnclassy.com;
> Received-SPF: None (protection.outlook.com: coolnclassy.com does not designate
>  permitted sender hosts)
> Received: from team.amasha.de (85.214.229.191) by
>  HE1EUR02FT037.mail.protection.outlook.com (10.152.10.205) with Microsoft SMTP
>  Server id 15.20.1185.13 via Frontend Transport; Mon, 1 Oct 2018 15:30:39
>  +
> X-IncomingTopHeaderMarker: 
> OriginalChecksum:AD6A9C63B554EDF179EC03C8E156AD5E1E8B14187C373D4F18043355097852DC;UpperCasedChecksum:E42459E5C34F8045AD1C2D47845333A3B048C575AB6FE7EF6DAB33A57829C4CE;SizeAsReceived:1216;Count:22
> X-LinkedIn-Class: EMAIL-DEFAULT
> X-LinkedIn-fbl: 1b78b1db96a2cbbc8aa355f68166b1231a66476d9dd
> List-Unsubscribe: 
> X-PHP-Originating-Script: 38789:bennett.php
> Bids-Hartman-Bridget: C4B4D96B
> Date: Mon, 1 Oct 2018 17:30:39 +
> Content-Transfer-Encoding: 7bit
> Content-Type: text/html; charset="UTF-8"
> Errors-To: wepeskx...@coolnclassy.com
> Content-ID: html-body
> Message-ID: <986d2ec5397dc568.b...@coolnclassy.com>
> Feedback-ID: email_notification_single_search_appearance_08:linkedin
> From: LinkedIn 
> Require-Recipient-Valid-Since: marinav._lionpsy...@hotmail.co.uk; Mon, 1 Oct 
> 2018 17:30:39 +
> Subject: Hi, you appeared in 8 search this week #5264
> X-LinkedIn-Id: a1443bac219fe813c
> To: "marinav._lionpsy...@hotmail.co.uk" 
> X-LinkedIn-Template: email_notification_single_search_appearance_08
> X-Mailer: Inroad
> X-Auto-Response-Suppress: All
> X-IncomingHeaderCount: 22
> Return-Path: epineu...@coolnclassy.com
> X-MS-Exchange-Organization-ExpirationStartTime: 01 Oct 2018 15:30:40.1785
>  (UTC)
> X-MS-Exchange-Organization-ExpirationStartTimeReason: Original Submit
> X-MS-Exchange-Organization-ExpirationInterval: 2:00:00:00.000
> X-MS-Exchange-Organization-ExpirationIntervalReason: Original Submit
> X-MS-Exchange-Organization-Network-Message-Id: 
> 70805765-41d4-44eb-4cb9-08d627b2d80b
> X-EOPAttributedMessage: 0
> X-EOPTenantAttributedMessage: 84df9e7f-e9f6-40af-b435-:0
> X-MS-Exchange-Organization-MessageDirectionality: Incoming
> X-Microsoft-Exchange-Diagnostics: 
> 1;HE1EUR02FT037;1:otLnmjKoNEcRohs7aebYnD3GiLv1VfLYlfDU13q23h3vGF0sGeaUDeKLhxNwy4VyBxQ6Cj5AyLuWIhKaaVFCEL+aq37A6sjrhkX4SkCoeHvtF2x/edrPoW2OuQ5Zh/fh
> X-Forefront-Antispam-Report: EFV:NLI;
> X-MS-Exchange-Organization-AuthSource:
>  HE1EUR02FT037.eop-EUR02.prod.protection.outlook.com
> X-MS-Exchange-Organization-AuthAs: Anonymous
> X-MS-PublicTrafficType: Email
> X-MS-Office365-Filtering-Correlation-Id: 70805765-41d4-44eb-4cb9-08d627b2d80b
> X-Microsoft-Antispam:
>  
> BCL:0;PCL:0;RULEID:(5000110)(711020)(4605076)(610169)(8291501071);SRVR:HE1EUR02HT135;
> X-Microsoft-Exchange-Diagnostics:
>  
> 1;HE1EUR02HT135;3:HgIPd/WNo6/W2nEbGL6A3FxbKnMiqfMtLI+pXYAIqURuaPFkvWEaQ61tNNBmL8qnzQJgkyn2zBrmJz2LgBQnEtUzDHwNpyhgrMQ+p4IoP1dY0+A03bRLCtuOAnTyrlpTUP3Eutt/yjfrYqgzKXPElDQViqugvwupxDI/CBI+crZIMnjrbrrg0cvpIKRrQ5ws1uJlHlTwKFHeWO1tiwMS2z/Bga+fapDDxo3VV0Mu8eV7+5zpXZOyszoZLFSKlOMRDO/bSC06P3dmbgfTQih+bTJet2sEZWJ6FCWkCdW0i71W6iSypbFDFsmhpTtMYFGJ;25:5UW6byCmbGQO/LlJnWCqRu0ZAfTNzBtF/c50yPUvcsqs2OtDw9otVfg2w1sD4A4EQWujHmTTIFJ8PqSV8V7QUqz0rHnmUXkZgWfzeSpYn3xacbJqxZpT/frF5GEZ1NkHYCOHDonOAlfjFrcmBsg+L0JRYwo8r/eePVN2USPoq6yG5e5DluT70x35rXd+RfKWTuRjifV+bTQ2CXs/KPQAwo/odwV6oEjrA/dz4EORTxOSsNe7HloeeqLXW1dtG6dC6mOWEo8a8/aA1yHZaNr90Zm31VlXat9bZEC7h9CW4U61B9MqfE37pWpHHOBWnF4kqbskOnYccq0doo7z95FK8A==;31:AjW8y9KFdWVd+j0G19XbVOQ9eAClLgNjVNTZDg/vwb1dSV2TyEhbiaVZjkzcuYJ1cKOW9reCX48jQmQPFlQnYm31+cHuWXzZD1Ab/GEl9HkgNaCed50fx5d+NDV/vFQ/1eAX7wiu8WhI1tDZbLL8+m66H6q+MXQbygf600eska+F6PKajoI+BUdHXDUcxAZDuoXqplApryyHRKlltJvANN5gAopO8zeGnrxVIx5NPmM=
> X-MS-TrafficTypeDiagnostic: HE1EUR02HT135:
> X-MS-Exchange-EOPDirect: true
> X-Sender-IP: 85.214.229.191
> X-SID-PRA: epineu...@coolnclassy.com
> X-SID-Result: NONE
> X-MS-Exchange-Organization-PCL: 2
> X-Exchange-Antispam-Report-Test:
>  
> UriScan:(186308324639673)(116415991822766)(190501279198761)(227612066756510)(240632212295403)(24487441151036);
> 

Re: [dmarc-discuss] Help

[Al Iverson via dmarc-discuss]

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

Re: [dmarc-discuss] Third party host email and DMARC

[Al Iverson via dmarc-discuss]

Can you show us a header? Preferably something like to a Gmail
account, so it shows the DMARC failure and authentication results?
On Mon, Jun 11, 2018 at 3:44 PM Jerry Warner via dmarc-discuss
 wrote:
>
>
> I'm still having fails when my web hosting company sends order
> confirmations to my customers.   I have my own mail server which
> handles most of my email however my ecommerce host handles order
> confirmations etc.  Those emails fail DMARC.
>
> Here's my spf key (edited).
>
> v=spf1 a mx a:MINE.com a:mail.MINE.com a:smpt5.volusion.com ~all
>
> Obviously Volusion is my web host and I have confirmed that
> smpt5.volusion.com is the server they send mail from.
>
> Volusion themselves are of no help. Depending on who I talk to they
> act like they've never heard of DMARC or they willl only help people
> if Voluison hosts your DNS and email.  In my case, they do neither.
>
> What do I have wrong?
>
>
> ___
> dmarc-discuss mailing list
> dmarc-discuss@dmarc.org
> http://www.dmarc.org/mailman/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)

Re: [dmarc-discuss] Newbie question: subdomain

[Al Iverson via dmarc-discuss]

Yeah, only the DMARC settings "trickle down" to a subdomain. Your SPF or
DKIM authentication does not. It really sounds like you just need to add an
SPF record for the subdomain.

Cheers,
Al Iverson
On Wed, May 30, 2018 at 10:28 AM Ken O'Driscoll via dmarc-discuss <
dmarc-discuss@dmarc.org> wrote:

> On Wed, 2018-05-30 at 09:44 -0400, Jerry Warner via dmarc-discuss wrote:
> > I'm reading over my reports and I see that I'm getting fails on valid
> > emails sent from my server when the sender uses a mail.server.com
> > name instead of just server.com.

> Hi Jerry,

> just a guess but does mail.server.com have its own SPF record? Because, it
> won't inherit anything in the SPF for server.com and if it's also not DKIM
> signing those emails then that would cause your DMARC failure.

> Ken.
> ___
> dmarc-discuss mailing list
> dmarc-discuss@dmarc.org
> http://www.dmarc.org/mailman/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 // wombatmail // 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)

Re: [dmarc-discuss] RUA vs RUF reports

[Al Iverson via dmarc-discuss]

Thank you all! This has been very insightful.

I'm going to turn aggregate reports back on, and maybe build something to
process them (really as a programming exercise, I know there are tools and
services existing already).

I'm surprised to learn of the low value of failure reports. But it's good
to learn. For now I'm going to leave them on so I can peek at them for
curiosity's sake.

Cheers,
Al Iverson

On Mon, May 28, 2018 at 9:16 AM John Levine  wrote:

> In article  you write:
> >This is very helpful, thank you! I guess I assumed the issuance of
forensic
> >(failure) reports was more common than you indicate; because at my day
job
> >we get gobs of them for various domains ...

> Looking at my last 100 or so failure reports, I see that that more
> than half of them are from large Chinese ISPs, mostly for random spam
> that faked one of my domains, a few for mailing lists.  (Who knew that
> there were NANOG subscribers in China?)  There's maybe a dozen from
> Linkedin, which are a mix of mailing lists and bounces from Office 365
> for a customer who, against my advice, hosts their mail there.
> Perhaps someday Microsoft will figure out how to do SPF alignment for
> bounces but not today.  Other than that it's from a smattering of tiny
> systems, almost all mailing list messages.

> None of them are anything I can fix here, and I am not inclined to
> tell mailing list operators how to run their lists.

> I find the aggregate reports occasionally interesting.  The volume is
> not huge.  I have over a dozen active mail domains and the total
> number of reports since 2012 is 143,000, which I store in an ordinary
> mail folder.  I give away a little perl script to which I feed the
> report messages so it can put the interesting bits in a mysql database.

> R's,
> John



-- 
al iverson // wombatmail // 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)

Re: [dmarc-discuss] RUA vs RUF reports

[Al Iverson via dmarc-discuss]

Well, I think that would depend on the use case, would it not?. I've got
one server and Google Apps, everything signs with DKIM, and SPF is
configured correctly. I don't really have any edge cases to look out for --
no other outsource service providers in the mix. The rare (for me) failed
message forensic reports provide feedback about other peoples' broken
mailing lists (and maybe someday examples of forgery, if somebody forges my
domain). In that scenario, I'm getting a daily "everything is OK" aggregate
report from Google and a few others that is of low value to me. I could
either set a filter to delete those reports, or I modify my DMARC record to
stop requesting them. Either way, this is reversible in the future.

For an ISP or corporate entity, I would be more inclined to agree with you.
Somebody in another department could set up with some other service
provider that handles some form of email messaging without enabling proper
authentication and you'd want to be able to catch that, and summary
(aggregate) information from the big guys would help immensely.

So I do get your point, but it doesn't see to fit my use case.

Cheers,
Al Iverson

On Sun, May 27, 2018 at 11:18 AM Vladimir Dubrovin <dubro...@corp.mail.ru>
wrote:


> Aggregated report contain all information, including SPF/DKIM/DMARC
> failures, but it doesn't contain forensic information (e.g. failed
> message Subject). Aggregated reports are supported by almost all large
> ESPs, so, if you have some troubles you will probably see it in
> aggregated report.

> Forensic report contains information about individual message failing
> SPF/DKIM/DMARC with some details (forensic information) regarding this
> message, e.g. message headers. The problem is there are very few peers
> sending forensic reports, so you may receive some reports, but should
> not expect to receive forensic reports in the case of failure.

> If you do not receive aggregated reports there is a very high chance to
> have configuration problem without noticing it.

> 27.05.2018 17:43, Al Iverson via dmarc-discuss пишет:
> > In a DMARC record, I see that rua= specifies the address to which
aggregate
> > feedback is to be sent, and ruf= specifies the address to which
> > message-specific forensic information is to be reported.
> >
> > I'm just a tiny bit confused about terminology-- could somebody confirm
for
> > me that I'm thinking of this correctly? I prefer only to receive failure
> > reports at this time. I don't want to receive summary reports telling me
> > that everything is AOK. That suggests to me that I should remove the rua
> > field but leave the ruf field.
> >
> > Have I got that right?
> >
> > Thanks,
> > Al Iverson
> >

> --
> Vladimir Dubrovin
> @Mail.Ru



-- 
al iverson // wombatmail // 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] RUA vs RUF reports

[Al Iverson via dmarc-discuss]

In a DMARC record, I see that rua= specifies the address to which aggregate
feedback is to be sent, and ruf= specifies the address to which
message-specific forensic information is to be reported.

I'm just a tiny bit confused about terminology-- could somebody confirm for
me that I'm thinking of this correctly? I prefer only to receive failure
reports at this time. I don't want to receive summary reports telling me
that everything is AOK. That suggests to me that I should remove the rua
field but leave the ruf field.

Have I got that right?

Thanks,
Al Iverson

-- 
al iverson // wombatmail // 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)

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

[Al Iverson via dmarc-discuss]

On Thu, May 24, 2018 at 5:11 AM, Vittorio Bertola via dmarc-discuss
 wrote:
>> Il 23 maggio 2018 alle 9.43 Alessandro Vesely via dmarc-discuss 
>>  ha scritto:
>>
>> ARC will allow message modifications.  However, it will require that 
>> Google/Apple/etc recognize SomeCo as a trusted forwarder, in order to 
>> believe reported authentication results.
>
> This is actually an area of concern to us: how will small scale operations, 
> like a server that only hosts a handful of mailing lists for local non 
> profits / open source projects / amateur groups etc, be able to be recognized 
> as trusted ARC intermediaries? The big players have reputation systems that 
> could be used for this as well, but what about everyone else? The risk is to 
> prompt more centralization in email services, which is not how the Internet 
> should work - or to prompt people to use instant messaging groups instead.

Those entities can handle it the same way they do today - rewriting
headers to become the sender, so any authentication falls to them.
This is basically already settled, if you want to run a mailing list
today and you want to maximize delivery of the mail, you have to do
this. Like this very list does.

Maybe the small guys will have to keep using this method?

I am curious to know the answer to your question. But also, I run a
small number of mailing lists myself, just fine, without ARC. So I am
not worried about having to directly support ARC. Maybe my opinion on
that will change? But for now, that is what it is.

Regards,
Al Iverson

-- 
al iverson // wombatmail // 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)

Re: [dmarc-discuss] dmarc-discuss Digest, Vol 72, Issue 2

[Al Iverson via dmarc-discuss]

So in this scenario, how is O365 denoting the DMARC failures? Is it
alerting, or is it something visible only when viewing the message
headers?

On Wed, Apr 18, 2018 at 12:48 PM, Ivan Kovachev via dmarc-discuss
 wrote:
> Hello Roland,
>
> thank you for the reply.
>
> I found this on Microsoft's website:
>
> "If you have configured your domain's MX records where EOP is not the first
> entry, DMARC failures will not be enforced for your domain.
> If you're an Office 365 customer, and your domain's primary MX record does
> not point to EOP, you will not get the benefits of DMARC. For example, DMARC
> won't work if you point the MX record to your on-premises mail server and
> then route email to EOP by using a connector. "
> I guess this is why we are currently not seeing any reports being sent by
> Office 365 if it has Mimecast in front of it and as part of the MX record
> for receiving domain.
>
> On 12 Apr 2018, at 20:00, dmarc-discuss-requ...@dmarc.org wrote:
>
> Send dmarc-discuss mailing list submissions to
> dmarc-discuss@dmarc.org
>
> To subscribe or unsubscribe via the World Wide Web, visit
> http://dmarc.org/mailman/listinfo/dmarc-discuss
> or, via email, send a message with subject or body 'help' to
> dmarc-discuss-requ...@dmarc.org
>
> You can reach the person managing the list at
> dmarc-discuss-ow...@dmarc.org
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of dmarc-discuss digest..."
>
>
> Today's Topics:
>
>   1. Re: Mimecast and Office 365 (Roland Turner)
>
>
> --
>
> Message: 1
> Date: Thu, 12 Apr 2018 15:57:20 +0800
> From: Roland Turner 
> To: dmarc-discuss@dmarc.org
> Subject: Re: [dmarc-discuss] Mimecast and Office 365
> Message-ID: <7a30d43c-5cd2-9da2-aff9-af92cc71c...@rolandturner.com>
> Content-Type: text/plain; charset="utf-8"; Format="flowed"
>
> On 11/04/18 22:07, Ivan Kovachev via dmarc-discuss wrote:
>
> Hello guys,
>
> I have three questions for you that I am unsure about and hoping that
> someone at Microsoft will be able to help:
>
> First two questions are related to Mimecast acting as inbound security
> gateway to O365:
>
> 1. When Mimecast acts as inbound gateway solution and it receives an
> email, it does DMARC checks and lets the email through to O365
> environment. Even if an email passes DMARC checks at Mimecast and the
> email is let through, then O365 also seems to also be doing DMARC
> checks but both SPF and DKIM fail because of the change that Mimecast
> does. As a results DMARC fails. My questions is, what is the best
> practice here in this scenario? Is there a way to turn off DMARC
> checks at O365? Mimecast suggest that it is whitelisted in O365 but
> that means that all the spam will be let through as well.
>
>
> DMARC checking should only occur at the host referred to be the MX
> record as SPF is still relevant for at least some email. I believe
> Office 365 has a trusted inbound relays option (i.e. Office 365 trusts
> the specified hosts to filter their email) although I can't quickly find it.
>
> Mimecast is apparently unwilling to change their service to stop
> damaging incoming messages that don't breach the policies being enforced
> (they unconditionally unpack and then repack every message, rather than
> only those whose contents they have reason to modify).
>
> 2. Would O365 send DMARC reports back to the sender in the above case?
> And, if O365 sends DMARC reports back to the sender then emails will
> be shown as originating from Mimecast but failing DMARC.
>
>
> Yes and yes if you've not listed Mimecast as a trusted inbound relay.
> (Assuming that the trusted inbound relays setting is not a figment of my
> imagination, one would hope that Office 365 would not set feedback in
> this case.)
>
> 3. Would O365 do DMARC checks for internal emails ie. O365 tenant
> employee to another O365 tenant employee? And would it send DMARC
> reports in this case?
>
>
> Yes and hopefully yes.
>
> - Roland
> -- next part --
> An HTML attachment was scrubbed...
> URL:
> 
>
> --
>
> Subject: Digest Footer
>
> ___
> dmarc-discuss mailing list
> dmarc-discuss@dmarc.org
> http://www.dmarc.org/mailman/listinfo/dmarc-discuss
>
> NOTE: Participating in this list means you agree to the DMARC Note Well
> terms (http://www.dmarc.org/note_well.html)
>
>
> --
>
> End of dmarc-discuss Digest, Vol 72, Issue 2
> 
>
>
>
> ___
> dmarc-discuss mailing list
> dmarc-discuss@dmarc.org
> http://www.dmarc.org/mailman/listinfo/dmarc-discuss
>
> NOTE: Participating in this list means you agree to the DMARC Note Well
> terms 

Re: [dmarc-discuss] Netscape.net?

[Al Iverson via dmarc-discuss]

There are a couple of possibilities.
1. There used to be secret backchannel agreements between ISPs to
treat certain domains as if they were p=reject. Some of this even
predates the DMARC spec. Could be the case here.
2. Some filter authors got too zealous and are treating p=none as if
it were p=reject.
3. Some filters come down really hard on an auth failure, regardless of DMARC.

We've run into this as well and in our application we deal with it by
having a DMARC table. We add domains to the DMARC table automatically
if they have a p=reject policy. But we can also add domains manually
to it, if it is in the domain owner's or users' best interest. Then we
rewrite headers for mail from that email domain as needed.

You might want to do the same.

Where this came in really handy lately is that a big client wants to
go to p=reject but isn't there yet. Right now they're just auditing,
and they see a lot of traffic that would bounce under p=reject due to
how our system handles forwarding of some replies. We dropped their
name into the DMARC table, and now that mail no longer uses their
domain, and it no longer shows up on their audit report, and thus that
particular mail forwarding scenario is solved, even before they went
to p=reject.

In my personal mailing list manager I also have a short list of
domains that I treat as though they are p=reject, regardless of the
true domain setting. I have found (anecdotally) that list mail from
some domains failing DMARC are more likely to go to spam at Gmail even
if p=none. Treating them as p=reject is one possible way to address
this.

Hope that helps.

Regards,
Al Iverson

--
Al Iverson
www.aliverson.com
(312)725-0130


On Thu, Mar 23, 2017 at 1:01 PM, Mark Fletcher via dmarc-discuss
 wrote:
> Hi All,
>
> One of our mailing list members, with a netscape.net email address, is
> getting DMARC bounces. That domain is set to p=none. Because of this we
> don't re-write her From lines. The netscape.net MX points to AOL, which we
> know does reject. And we're seeing AOL DMARC bounces for her messages.
>
> It seems to me that we need to treat netscape.net addresses as p=reject, as
> they seem to have misconfigured their DMARC record. Or am I misunderstanding
> what's happening (completely possible)?
>
> Thanks,
> Mark
>
> ___
> dmarc-discuss mailing list
> dmarc-discuss@dmarc.org
> http://www.dmarc.org/mailman/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] Getting to reject, was :Re: FortiNet’s FortiMail DMARC implementation

[Al Iverson via dmarc-discuss]

Carl, this is great to hear. Thanks for sharing with us.

Best regards,
Al Iverson

--
Al Iverson
www.aliverson.com
(312)725-0130


On Fri, Nov 25, 2016 at 4:36 AM, Carl Windsor via dmarc-discuss
 wrote:
>>I would suggest a note saying that Fortinet's implementation is
>>known to be fatally buggy.
>
> Hi DMARC Group, I am the Product Manager @ Fortinet for FortiMail and can
> confirm that this was not by design but a bug.  As of 5.3 interim build 625
> we respect the p=none directive and this will be rolled in to the next patch
> release (5.3.8).
>
> Carl Windsor
>
>
>
> ___
> dmarc-discuss mailing list
> dmarc-discuss@dmarc.org
> http://www.dmarc.org/mailman/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 policy change for mail.ua / corp.mail.ru

[Al Iverson via dmarc-discuss]

> We will follow the same process that we have used for Yahoo and AOL. We will
> simply add the new domain to our banned list, and not allow participation
> from accounts with those domains in our 20 listserv lists.

So you're treating real life like it's that episode of TNG where Dr.
Crusher got caught in a donut-shaped pocket universe and eventually
everybody else disappeared?

Why not consider upgrading to something that handles DMARC just fine,
like a later version of Mailman, instead of kicking out users because
of a security choice made by their ISP? Your response seems a bit
dramatic.

Regards,
Al Iverson

--
Al Iverson
www.aliverson.com
(312)725-0130
___
dmarc-discuss mailing list
dmarc-discuss@dmarc.org
http://www.dmarc.org/mailman/listinfo/dmarc-discuss

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

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

[Al Iverson via dmarc-discuss]

Scott, I don't really see any difference in the class of problem. You could
choose to outsource email it to Google Apps or Microsoft Office 365 if you
don't want to figure this stuff out yourself. Many do, from SMB to
enterprise level, even though email is core to just about every company's
business. For some, that's very much the reason to job it out to a company
who focuses on email as an area of expertise.

On the flip side, I disagree with regard to your take on running a blog.
Anybody can do it, but many people outsource that as well. I personally
host my blog with a third party service, because self-hosted Wordpress is
one of the most hacked into things out there and I want no part of that
noise, even though in theory I could handle it. I know I'm not the only
one, and just about anything in this paragraph could similarly apply to
email.

Regards,
Al Iverson


--
Al Iverson - Minneapolis - (312) 275-0130
Simple DNS Tools since 2008: xnnd.com
www.spamresource.com & aliverson.com

On Mon, Feb 15, 2016 at 1:35 PM, Franck Martin via dmarc-discuss <
dmarc-discuss@dmarc.org> wrote:

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

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

[Al Iverson via dmarc-discuss]

On Mon, Feb 8, 2016 at 1:51 PM, John R Levine via dmarc-discuss
 wrote:
>> It is even worse than I thought, you really want to stop efforts in
>> fighting phish, by muddling the waters between real domains and fake ones
>
>
> There's no muddling going on.  dmarc.fail is a real domain that should have
> an excellent reputation since it sends no phish.

I think Franck is right. It is muddying the waters by introducing a
wholly other domain that has nothing to do with the list or the
subscriber. Not seeing why anybody would recommend that as a best
practice.


--
Al Iverson - Minneapolis - (312) 275-0130
Simple DNS Tools since 2008: xnnd.com
www.spamresource.com & aliverson.com
___
dmarc-discuss mailing list
dmarc-discuss@dmarc.org
http://www.dmarc.org/mailman/listinfo/dmarc-discuss

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

Re: [dmarc-discuss] Office 365 does not repect dmarc rejection policy!?

[Al Iverson via dmarc-discuss]

Larry, even a non-profit has to consider that something bought and
paid for does not last forever. Not a commercial software package, nor
the physical hardware it runs on. It wasn't due to DMARC, it would be
due to something else. I'd suggest changing your stance before you end
up the Last Man Standingyou can nudge people away from Yahoo
today, perhaps. Maybe even tomorrow. But that is going to stop
working, because more and more sites are rolling out DMARC.

--
Al Iverson - Minneapolis - (312) 275-0130
Simple DNS Tools since 2008: xnnd.com
www.spamresource.com & aliverson.com


On Wed, Nov 25, 2015 at 1:36 PM, Jacob Evans via dmarc-discuss
 wrote:
> Wouldn't you just upgrade?
>
> http://www.lsoft.com/news/2014/listserv160-2014a-us.asp
>
> Not to mention you could easily patch your spoofing problem by relaying off
> a postfix server to do the header manipulation for compliance.
>
> Otherwise, DMARC is as good as SPF, solves the problem, but not respected
> and worthless. It's up to people like yahoo and gmail to 'bully' compliance,
> forcing some standardizations, just like they are doing with FCrDNS and
> IPv6
>
> -Jake
>
> 
> From: "Larry Finch via dmarc-discuss" 
> To: "Nicolás via dmarc-discuss" 
> Sent: Wednesday, November 25, 2015 12:46:31 PM
> Subject: Re: [dmarc-discuss] Office 365 does not repect dmarc rejection
> policy!?
>
>
>
>
> On Nov 25, 2015, at 9:13 AM, Jacob Evans 
> wrote:
>
> Larry,
> host gmail-smtp-in.l.google.com[2607:f8b0:400e:c01::1b] said: 550-5.7.1
> Unauthenticated email from appalachiatech.com is not accepted due to
> 550-5.7.1 domain's DMARC policy. Please contact administrator of
> appalachiatech 550-5.7.1 .com domain if this was a legitimate mail.
> Please
> visit 550-5.7.1  https://support.google.com/mail/answer/2451690 to learn
> about DMARC 550 5.7.1 initia..
> -Jake
>
> 
>
>
> I manage 15 listserv mailing lists on a non-profit server site. We do not
> play games to make our outgoing messages DMARC compliant, because it would
> require updating our listserv license at a cost of $6,000, and our annual
> budget is $1,500. Mail from ISPs with a REJECT policy are delivered to our
> gmail addressees, but marked as potential spam. But once the user approves
> them future messages from a list are delivered without warnings. They are
> still not delivered to ISPs that respect the REJECT policy, of course. But
> Microsoft is not a problem either. We have solved any DMARC issues by not
> allowing users of ISPs with REJECT policies to post directly, although
> occasionally one gets through. Instead, a moderator intercepts the message
> and reposts it. And asks the sender to stop using Yahoo. Most have complied.
>
> Larry
>
> --
> 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)

___
dmarc-discuss mailing list
dmarc-discuss@dmarc.org
http://www.dmarc.org/mailman/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?

[Al Iverson via dmarc-discuss]

On Fri, Oct 23, 2015 at 9:54 PM, Scott Kitterman via dmarc-discuss
 wrote:

>>ARC should be helpful in that perhaps non-exotic situation.
>
> Could be.  I certainly don't claim it's not potentially useful.  My concern 
> is that it seems to be marketed as a solution to the DMARC mailing list 
> problem and as far as I can tell, its potential utility is orthogonal to that.

The authors of ARC think it more directly applies to the issue of list
mail. Let's start from assuming that they might have a point and we'll
see how the first implementations of this work. But, if it doesn't
really address the issue, it's pretty easy to ignore. Most MLM tools
that want to keep working have already implemented DMARC workarounds
-- I can't see those going away unless ARC provides a better
alternative. And maybe not even then, who knows.

>From my own perspective, I'm unclear on how well this will work. I
assume the chain process is based on addressing anything thrown at at
it; mailing list posts going through mail forwarding; ARC on both
would in theory keep authentication intact and prevent p=reject policy
rejections. But we're talking the 1% of the 1% (of the 1%?), it feels
like the use cases might get more and more far out.

Regards,
Al Iverson

--
Al Iverson - Minneapolis - (312) 275-0130
Simple DNS Tools since 2008: xnnd.com
www.spamresource.com & aliverson.com
___
dmarc-discuss mailing list
dmarc-discuss@dmarc.org
http://www.dmarc.org/mailman/listinfo/dmarc-discuss

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

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

[Al Iverson via dmarc-discuss]

How about you don't just execute attachments sent to a reporting address?
It's all meant to be processed programmatically based on its contents, not
clicked on by a human in Windows 98. In 2015, virus filtering this feed is
about as nonsensical as spam content filtering the abuse mailbox. Even if
.com is unsafe, that filter is still now out of date and needs an update
or an exemption at this point.

On Tue, Aug 25, 2015 at 2:50 PM, Franck Martin via dmarc-discuss 
dmarc-discuss@dmarc.org wrote:

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

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

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

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

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

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

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



 I'd disagree about content filtering completely. There are some file
 extensions that are inherently dangerous in the Windows world and .COM is
 one of them. .COM is possibly the worst of the lot because of the one-two
 punch that users don't associate it with executable code (it's only
 supported for legacy reasons), and because users do associate it with the
 web in general. It's half a technical attack and half a social attack, so
 no, malware cannot simply use a different name to get the same result.

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

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

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



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

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



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

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




-- 
Al Iverson | Minneapolis, MN | (312) 725-0130
aliverson.com | spamresource.com | @aliverson
___
dmarc-discuss mailing list
dmarc-discuss@dmarc.org
http://www.dmarc.org/mailman/listinfo/dmarc-discuss

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

Re: [dmarc-discuss] Mail delivery failed: returning message to sender

[Al Iverson via dmarc-discuss]

I agree that it looks like a bum forwarder setup from what you've
posted. Forgive the dumb question -- why are you sending reports to
dmarc.org? Are they allowing random third parties to send it reports
to them for analysis? I can't imagine sending reports of what could be
my mail to some random other third party. Is this some common thing to
help troubleshoot the spec, that I was ignorant of?

Regards,
Al Iverson

On Thu, Jul 9, 2015 at 10:20 AM, Sebastian Schweizer via dmarc-discuss
dmarc-discuss@dmarc.org wrote:
 Am I the only one who gets bounces for reports to dmarc.org's reporting
 address repo...@dmarc.org?

 dragon.trusteddomain.org (which is the MX for dmarc.org) sends these
 bounces:
 - The following addresses had permanent fatal errors -
 repo...@blackops.org
 (reason: 550 5.1.1 repo...@blackops.org... User unknown)
 (expanded from: repo...@dmarc.org)


 For me it looks like a faulty forwarder at their site...

 --
 Sebastian


 On 09.07.2015 15:33, Jacob Evans via dmarc-discuss 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 mailto:dmarcrepo...@mail.cnn.com

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

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

 Relay access denied

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

SMTP error from remote mail server after RCPT
 TO:dmarc-foren...@emedia.co.uk mailto: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 mailto:dmarc_i...@service.alibaba.com

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

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

 dma...@email4-beyond.com mailto:dma...@email4-beyond.com

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

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

   dmarc_...@wrtech.com mailto:dmarc_...@wrtech.com

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

 host mx1.emailsrvr.com [173.203.2.36]: 550 5.7.1
 dmarc_...@wrtech.com mailto: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)


 ___
 dmarc-discuss mailing list
 dmarc-discuss@dmarc.org
 http://www.dmarc.org/mailman/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 | Minneapolis, MN | (312) 725-0130
aliverson.com | spamresource.com | @aliverson

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

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

Re: [dmarc-discuss] Mail delivery failed: returning message to sender

[Al Iverson via dmarc-discuss]

Aha, that makes sense now. Thanks.

On Thu, Jul 9, 2015 at 10:53 AM, Tim Draegen t...@eudaemon.net wrote:
 On Jul 9, 2015, at 11:41 AM, Al Iverson via dmarc-discuss 
 dmarc-discuss@dmarc.org wrote:

 I agree that it looks like a bum forwarder setup from what you've
 posted. Forgive the dumb question -- why are you sending reports to
 dmarc.org?


 No, this is just where dmarc.org is asking for reports to go.

 % dig _dmarc.dmarc.org txt
 v=DMARC1\; p=none\; pct=100\; rua=mailto:repo...@dmarc.org\; 
 ruf=mailto:repo...@dmarc.org;

 Indeed, it looks like a broken config on dmarc.org's end.  They've been 
 redoing a lot of their stuff now that it is an official non-profit effort.

 -= Tim





-- 
Al Iverson | Minneapolis, MN | (312) 725-0130
aliverson.com | spamresource.com | @aliverson
___
dmarc-discuss mailing list
dmarc-discuss@dmarc.org
http://www.dmarc.org/mailman/listinfo/dmarc-discuss

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

Re: [dmarc-discuss] SPF Check issue on Google Reports

[Al Iverson via dmarc-discuss]

I have not seen this, and I use Google to check DKIM and SPF for many
hundreds of domains.

Perhaps if you were to offer up the domain name we could help to check
for any issue.

First thing I would look at is, do all of your DNS servers reliably
return the same results? If you have 3-4 DNS servers and one of them
doesn't return the right info, this could conceivably cause what you
are seeing.

Regards,
Al Iverson

On Mon, Sep 15, 2014 at 3:14 PM, Daniel Brito via dmarc-discuss
dmarc-discuss@dmarc.org wrote:
 Hi,

 I have turned on the DMARC for domain that i am responsable and i am
 receiving reports from Google, Yahoo and Hotmail. In my domain, i configured
 the SPF and DKIM correctly. All reports seems demonstrate this, but Google
 reports sometimes fails on SPF check.

 In the Google Report's, the spf failed and passed for the same IP. This IP
 is configured in SPF and should pass, this happened only in the google
 report's. This seems to be the same problem that was discussed here:
 http://lists.dmarc.org/pipermail/dmarc-discuss/2013-July/002067.html.

 Someone faced this problem recently? There is something wrong with the
 Google Report?

 Thanks
 Best regards,
 Daniel Brito

 ___
 dmarc-discuss mailing list
 dmarc-discuss@dmarc.org
 http://www.dmarc.org/mailman/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 | Chicago, IL | (312) 725-0130
spamresource.com / fhsdh.com / @aliverson
___
dmarc-discuss mailing list
dmarc-discuss@dmarc.org
http://www.dmarc.org/mailman/listinfo/dmarc-discuss

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

Re: [dmarc-discuss] SPF Check issue on Google Reports

[Al Iverson via dmarc-discuss]

On Mon, Sep 15, 2014 at 4:13 PM, Dave Warren via dmarc-discuss
dmarc-discuss@dmarc.org wrote:
 On 2014-09-15 13:55, Al Iverson via dmarc-discuss wrote:

 First thing I would look at is, do all of your DNS servers reliably
 return the same results? If you have 3-4 DNS servers and one of them
 doesn't return the right info, this could conceivably cause what you
 are seeing.

 One other thought, beyond what Al said... Any chance you've started
 delivering to Google via IPv6, but your SPF only covers your IPv4 IP space?

Especially since that exact scenario happened to me, didn't realize my
new VPS came with IPv6 already configured and routable...

Al

-- 
Al Iverson | Chicago, IL | (312) 725-0130
spamresource.com / fhsdh.com / @aliverson
___
dmarc-discuss mailing list
dmarc-discuss@dmarc.org
http://www.dmarc.org/mailman/listinfo/dmarc-discuss

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

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

[Al Iverson via dmarc-discuss]

On Sun, Jun 8, 2014 at 12:22 AM, David Woodhouse via dmarc-discuss
dmarc-discuss@dmarc.org wrote:

 Any bank *not* signing its direct-to-customer email should be prosecuted
 as an accessory to fraud which it is enabling by actively training its
 customers to succumb to phishing :)

Since none of them do sign their mail with S/MIME today, will you be
leading that prosecutorial effort personally? What kind of lawyers do
you have lined up for the effort?

-- 
Al Iverson | Chicago, IL | (312) 725-0130
spamresource.com / fhsdh.com / @aliverson
___
dmarc-discuss mailing list
dmarc-discuss@dmarc.org
http://www.dmarc.org/mailman/listinfo/dmarc-discuss

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

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

[Al Iverson via dmarc-discuss]

On Sun, Jun 8, 2014 at 12:13 AM, Dave Crocker d...@dcrocker.net wrote:
 On 6/8/2014 1:26 AM, Al Iverson via dmarc-discuss wrote:
 On Sat, Jun 7, 2014 at 12:44 PM, Dave Crocker via dmarc-discuss

 Keeping in mind that the mailing list scenario has always been
 legitimate use,

 SMTP relay was a legitimate use case (or at least was very loudly
 claimed to be by those angry about relay blocking).

 Sorry, no.  Use by unauthorized users is not a legitimate use case.

I didn't say unauthorized.

 Again, closing relays carried an entirely adequate alternative via port
 587 for authorized users.  No such equivalence is available when DMARC
 breaks mailing list use.

Not at first it didn't -- it looks like port 587 submission was
specified in RFC 2476 which was December 1998. The relay wars were
underway by then and it took some time to garner acceptance and
adoption.

 the concern is that we may be left with a long-term
 barrier to that use, with no attendant long-term benefit.

 I think there's a good chance that the barrier melts away in the long
 term. Specifically, the mailing list usage barrier. Mailman, Yahoo
 Groups, Google Groups, and various commercial providers have already
 implemented changes to that end. I feel like a lot of the barrier has
 melted away already.

 You seem to be confusing work-around with equivalent function.  What
 we have is increasing use of work-arounds that defeat DMARC and train
 the community to accept mail the employs the work-around.  As such it
 eliminates long-term benefits of DMARC.

I don't know that I agree, but that was a helpful clarification of
your point and I appreciate it.

 If I can keep my domain out of the from address of bad mail forever,
 that's a long term benefit to me. How does that not sustain?

 An assertion like that focuses on a syntactic point, rather than a
 semantic one.

 I'll bet you don't actually care about the From address content, on its
 own, but that you really care about receivers thinking that mail is from
 you when it isn't.  I know I do.  That's the real and higher-level concern.

I guess it might be more accurate to say that I care about both. But I
can't speak for AOL and Yahoo.

 You believe that there haven't been explanations for the 'why' provided???

Yes, or more specifically that there's not been very much detail or
explanation, just lots of angry. So I decided to ask questions to try
to better understand.

Regards,
Al Iverson
___
dmarc-discuss mailing list
dmarc-discuss@dmarc.org
http://www.dmarc.org/mailman/listinfo/dmarc-discuss

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

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

[Al Iverson via dmarc-discuss]

On Sat, Jun 7, 2014 at 12:44 PM, Dave Crocker via dmarc-discuss
dmarc-discuss@dmarc.org wrote:
 On 6/7/2014 7:31 PM, Franck Martin wrote:
 But the claim is that these workarounds will mainly happen after you do 
 DMARC p=reject. This data is coming in a not too distant future now.

 Keeping in mind that the mailing list scenario has always been
 legitimate use,

SMTP relay was a legitimate use case (or at least was very loudly
claimed to be by those angry about relay blocking).

 the concern is that we may be left with a long-term
 barrier to that use, with no attendant long-term benefit.

I think there's a good chance that the barrier melts away in the long
term. Specifically, the mailing list usage barrier. Mailman, Yahoo
Groups, Google Groups, and various commercial providers have already
implemented changes to that end. I feel like a lot of the barrier has
melted away already.

 The fact that there is short-term benefit is not the issue; it is that
 the benefit might not sustain.

If I can keep my domain out of the from address of bad mail forever,
that's a long term benefit to me. How does that not sustain?

The issue of lookalike domains was mentioned. This is an extant
badness vector. It gets addressed through multiple means, as it has
previously. It pops up, it gets a bad reputation, it gets blocked.
Domain rep, IP rep, content rep, can and will all still apply.

I think there's a legitimate exercise here to explore and I think we
would all benefit from a list or detail of concerns that people have,
so we can begin to consider whether or not we would agree that they're
concerns.

To that end, I think anybody who's going to say there's no long term
benefit really should only say that when including a more detailed
statement of why that would be, because honestly, obviously, DMARC
proponents don't necessarily start from that point of view and I'm
sure I'm not the only one who would need more information to better
understand the concerns.

Regards,
Al Iverson
___
dmarc-discuss mailing list
dmarc-discuss@dmarc.org
http://www.dmarc.org/mailman/listinfo/dmarc-discuss

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

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

[Al Iverson via dmarc-discuss]

On Fri, Jun 6, 2014 at 3:59 PM, J. Gomez via dmarc-discuss
dmarc-discuss@dmarc.org wrote:

 Crazy analogy? Apt analogy?

I find it apt, having lived through the open relay wars. The actors
are the same here; just the names have changed. Some saying shrug,
just deal with it, some saying it's the death of email as we know it
and doesn't stop spam at all. They're both right, but only to a
degree. No, it's not a magic solution to the spam problem, as it
closes only one door, not all of them.

At least nobody's threatened to sue me over DMARCI don't really
miss the crazy legal threats and conspiracy theories surrounding open
relay blocking. Though I have had people I respected aim a couple of a
low punches in response to me advocating that they just deal with
DMARC and get over it.

Cheers,
Al


-- 
Al Iverson | Chicago, IL | (312) 725-0130
Twitter: @aliverson / 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)

Re: [dmarc-discuss] About that From: field

[Al Iverson via dmarc-discuss]

On Sat, May 10, 2014 at 9:02 PM, Dave Crocker d...@dcrocker.net wrote:

 My question was rather carefully formed.

The intent, one assumes, of this list, is to examine and discuss
operational issues that relate to DMARC. It seems as though the
existence of a bug is being inferred; the archives don't reflect what
recipients receive, I read. But in what way? The problem statement is
going unstated, unclarified. It is, to borrow a phrase, not rather
carefully formed.

Here's a possible way to start: I think the web archive of this
mailing list does not reflect what recipients received because it
__. I think that is bad because .

Do you think the web archive doesn't reflect what email subscribing
recipients received? In what way, specifically? Is it material, and is
it harmful?

Regards,
Al Iverson
-- 
Al Iverson | Chicago, IL | (312) 725-0130
Twitter: @aliverson / 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)

Re: [dmarc-discuss] About that From: field

[Al Iverson via dmarc-discuss]

On Sun, May 11, 2014 at 4:43 PM, Dave Crocker d...@dcrocker.net wrote:
 Although it does prompt the question of why you are working so hard to
 avoid responding to the substance of the question I asked.

 And no, I'm not expecting a useful response.

Dave, I apologize for frustrating you. Neither you nor I have any
particular standing relating to the list's administration, and thus,
little recourse when an attempt to steer a conversation in a certain
direction is rebuffed. What you call carefully formed, I look at and
go, interesting questions, but very cart before the horse, and I'm not
a student in attendance at a lecture you're presenting, so, no, you
don't get to call on me and demand that I answer you. I find the
tactic distasteful and declined to respond to it as you desired.

Back to the point, which is: I'd like to understand the operational
issue before I'm willing to jump to the existential crisis of what I
should or shouldn't want from a list archive. That doesn't mean I'm
not willing to answer your questions -- I'm very much willing to do
so. But you've jumped ahead in the discussion. I still don't
understand what changed and why it is considered bad.

I saw John say, the mail going into the archive isn't the same as the
mail going out to the list. In what way? I look at the archive and I
see several ways. I see different headers. Obfuscation of email
addresses to prevent spambot harvesting. Web markup and navigational
links inserted, to account for the very different protocols used to
interact with a web page versus an email message. And, of course, the
fact that the archive is showing you a representation of the
submitter's address, even though the emailed copy may have had a
rewritten from address to deal with DMARC policy. A web archived copy
of a message posted to the list doesn't look like the email copy I
received, in a bunch of different ways.

Regards,
Al Iverson
___
dmarc-discuss mailing list
dmarc-discuss@dmarc.org
http://www.dmarc.org/mailman/listinfo/dmarc-discuss

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

Re: [dmarc-discuss] About that From: field

[Al Iverson via dmarc-discuss]

On Fri, May 9, 2014 at 9:32 PM, Dave Crocker d...@dcrocker.net wrote:
 On 5/9/2014 7:10 PM, Al Iverson via dmarc-discuss wrote:
 This feels like complaining for complaining's sake.

 You think that it's irrelevant that a mailing archive archives something
 different from what mailing list members receive???

I'm trying to figure out what invisible yet inviolable rule is being
broken here. What does something different in this case mean and how
is it bad?

Regards,
Al Iverson
___
dmarc-discuss mailing list
dmarc-discuss@dmarc.org
http://www.dmarc.org/mailman/listinfo/dmarc-discuss

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

Re: [dmarc-discuss] About that From: field

[Al Iverson via dmarc-discuss]

On May 9, 2014, at 8:48 PM, John Levine via dmarc-discuss 
dmarc-discuss@dmarc.org wrote:

 There's only a single author posting here now. Just thought I'd mention it.
 It's definitely broken some functionality I rely on - some of it easily 
 fixable, some not.
 
 I thought for sure the archives would have broken, but it doesn't look like 
 it:
 
http://lists.dmarc.org/pipermail/dmarc-discuss/2014-May/002817.html
 
 Oh, wow.  The mail going into the archive isn't the same as the mail
 going out to the list.  I wonder what we'll fix next.

This feels like complaining for complaining's sake. Do you prefer that the from 
address in the archive be similarly modified, or do you prefer to limit the 
modification to only exactly when necessary?

Regards,
Al Iverson
___
dmarc-discuss mailing list
dmarc-discuss@dmarc.org
http://www.dmarc.org/mailman/listinfo/dmarc-discuss

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