Re: [dmarc-discuss] opendmarc and response from Mailer Daemon

[Roland Turner via dmarc-discuss]

Hi Kazik,

This is dmarc-discuss, a list for discussion the standard and protocol. 
You are perhaps looking for opendmarc-users 
 which 
discusses that particular implementation.


- Roland



On 6/9/21 2:14 pm, Kazik K. via dmarc-discuss wrote:

Hi,

I have installed and configured opendmarc on the receiving SMTP server.

I have noticed behavior such as the following: when the message is 
from Mailer Daemon - when 'MAIL From: <>' is used during the SMTP 
dialog, and the From: header line is a valid sender's domain, 
opendmarc marks such messages as 'dmarc=fail'. Consequently, when the 
sender's domain DNS _dmarc record contains p=quarantine/reject, the 
mail will not reach the recipient mailbox.


Does running opendmarc on the receiving server prevent receiving 
messages from Mailer-Daemon?

What should I do to get my users to receive such messages?

Kazik

___
dmarc-discuss mailing list
dmarc-discuss@dmarc.org
http://www.dmarc.org/mailman/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] Correct counting of DNS lookups for SPF record containing MX mechanism

[Roland Turner via dmarc-discuss]

On 8/7/21 3:17 am, Jonathan Kamens via dmarc-discuss wrote:

It's not useful to come back and say, "Well, I mean, if they did 
things differently, then this wouldn't be an issue." They're not doing 
things differently, and they don't want to do things differently. It's 
our job to facilitate them being able to make their emails look the 
way they want to securely. It's not our job to tell them that they 
can't make their emails look the way they want to or can't employ 
third-party service providers to send out emails on behalf of their 
domains. Either of those is a non-starter. 


+1


- Roland


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

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

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

[Roland Turner via dmarc-discuss]

On 8/7/21 2:11 am, Alessandro Vesely via dmarc-discuss wrote:

> A mailbox provider is only one of the service providers that an organisation 
> might contract to send email on its behalf. Other common examples include:
> 
>   * Marketing automation (list management, sending mailouts, analytics)

>   * CRMs, where sellers use the CRM itself to send messages to their customers
>   * Subscription management systems that send expiry reminders
>   * Helpdesk systems that send responses to user requests
> 
> There are dozens or hundreds of less common examples.



I see.  I note that the examples you mention, except some kind of marketing,
need to receive mail, besides sending it.  Indeed, being bidirectional is a
peculiar email characteristics.  So, if a service can be integrated with a mail
system,


There's either no requirement for reception by the service provider (CRM 
case, subscription management case), or the level of "integration" is 
just an email alias (helpdesk case). Adding an account, maintaining 
credentials, etc. is implementation friction which those service 
providers avoid wherever they can.




  then it should be able to use its incoming as well as outgoing servers.


What someone/something else "should" do is not relevant in a DMARC 
discussion. The should-based engineering approaches to this problem of 
~15 years ago were difficult, contentious, and ineffective. One of key 
realisations in DMARC was that the lower the burden on domain 
registrants (i.e. the lower the adoption friction), the more widespread 
implementation will be. DMARC succeeds in large part because it avoids 
all avoidable friction for the least-engineering-savvy participants: the 
domain registrants, no matter how untidy the resulting engineering looks.


While there is some engineering appeal in the argument that you're 
making, it's overwhelmed by the importance of widespread adoption. As in 
many other contexts, systems that gain adoption are those which address 
the world as it is, not as it "should" be.




   Otherwise, it deserves using its own subdomain.


"Deserves" is even less relevant than "should". In any event, you're 
proposing exposing an implementation artefact to end-users, which is not 
even sound engineering.




Most likely, technology-impaired companies don't even host their own DNS.  The
DNS providers who do that for them should have an adequate level of expertise,
though.
...

The list of DNS providers seems to have grown quite a bit since the last time I
checked.  Freeing customers from SPF pains could be an element of distinction.


This is an interesting idea. If the market for it is real then your 
fortune awaits :-)


I would point out that DNS-content services of this type are quite rare. 
About the only mass-market examples that I can think of are:


 * DNSSEC key rotation, integrated with domain registrar services
 * DNS-based delivery optimisation (i.e. not IP anycast), integrated
   with CDNs
 * CloudFlare's proxying domain-root A records to permit aliasing the
   root while not breaking DNS (by putting CNAMEs alongside NSs, which
   they did for some time).

It's really quite rare, and generally only arises as an essential part 
of the related service. I'd hazard a guess that the amount of additional 
revenue that can be obtained through implementing and offering such 
services more generally doesn't warrant the effort.



- Roland


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

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

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

[Roland Turner via dmarc-discuss]

On 7/7/21 4:03 pm, Alessandro Vesely via dmarc-discuss wrote:


If I outsourced my mail to google (to stick to the example) what other
providers' SPF record do I have to include?  Oh yes, John said "to several
providers".  Why does one need more than one provider, then?


A mailbox provider is only one of the service providers that an 
organisation might contract to send email on its behalf. Other common 
examples include:


 * Marketing automation (list management, sending mailouts, analytics)
 * CRMs, where sellers use the CRM itself to send messages to their
   customers
 * Subscription management systems that send expiry reminders
 * Helpdesk systems that send responses to user requests

There are dozens or hundreds of less common examples.

DKIM is a more scalable approach, but it's also harder to get right 
initially. (It's extremely simple once it's working, but...)




Dmarcian has a good SPF compiler already.  It is somewhat unpractical, as you'd
need to copy its result to your zone file, and repeat that operation as often
as needed.  It doesn't sound awful to call it from a cron job.


This is a *vastly* higher level of technical expertise than most 
organisations have available for this.




It is easier to adapt existing software to your special needs than change the
rest of the world.


The target is not limited to technical organisations who are capable of 
doing this.



- Roland


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

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

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

[Roland Turner via dmarc-discuss]

On 7/7/21 2:57 am, John Levine via dmarc-discuss wrote:


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


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


Yes, precisely that.


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


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


+1


- Roland


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

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

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

[Roland Turner via dmarc-discuss]

On 22/5/21 7:41 am, Brandon Long via dmarc-discuss wrote:

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

or more general DoS-style protections.

At least at one point we definitely saw enough senders requiring too 
many lookups that we cared more about

trying to find a positive evaluation than downside from doing more.


I'd suggest that a resolution to this might be to expand the finite 
limit (I've also had trouble with the 10 lookup limit, even for a small 
organisation), rather than to burden every implementation with reliance 
upon prioritisation capability and other DoS mitigation techniques 
merely to make DMARC safe to operate.


The interests of very large receivers are particularly important of 
course, but it would appear desirable to maintain the ability for 
receivers at any size to implement.


- Roland


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

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

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

[Roland Turner via dmarc-discuss]

On 10/3/20 02:15, Ivan Kovachev via dmarc-discuss wrote:


How can DMARC validation be turned off or disabled at Office 365 for the above 
scenario?


Hopefully it is obvious that that is a question for Microsoft support, 
rather than for dmarc-discuss?



On your broader question: it is not normal for a service provider that 
provides MX service to decide to automatically disable protections 
merely on the basis that the relevant MX record in its DNS cache points 
somewhere else. Instead, an explicit configuration of something like a 
trusted relay is usually required. Given Microsoft's customer base, it 
would not be surprising if 365 had such a feature.


(ARC might also help if (a) Barracuda were willing to seal, and (b) 
Microsoft were willing to trust Barracuda's authentication and sealing 
process, but these are longer-term approaches.)


- Roland


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

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

Re: [dmarc-discuss] SPF Macros

[Roland Turner via dmarc-discuss]

Hi Ivan,

It's been a while (several years) since I tried using them, but a 
surprising number of receivers honoured them (meaning that some internal 
structure of receivers was made visible); those that didn't appeared to 
disregard the SPF result.


- Roland



On 31/12/19 12:32 am, Ivan Kovachev via dmarc-discuss wrote:

Hello,

Are SPF macros widely supported / evaluated correctly by recipients? Is there 
any major players that do not understand SPF macros and treat it as SPF fail 
when encountered?
___
dmarc-discuss mailing list
dmarc-discuss@dmarc.org
http://www.dmarc.org/mailman/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] Re-verifying external report destinations

[Roland Turner via dmarc-discuss]

On 11/11/19 6:22 pm, Steven M Jones via dmarc-discuss wrote:


This has been a bit of a problem, as non-verification of “ruf” addresses 
combined with people copying sample DMARC records in their deployments led to 
what I have to assume are violations of GDPR and several other privacy regimes.

I would hope people would see reporting address verification as an important 
mitigation of concerns about “ruf” reporting. My fear is that instead it makes 
the lawyers say “no” a few microseconds faster...


Speaking entirely speculatively: it occurs to me that as almost no-one 
is sending failure reports other than to domain registrants with whom an 
agreement is in place (either directly or through an intermediary), it 
is entirely possible that some receivers sending ruf reports aren't 
looking at the ruf field at all, but are instead manually configuring an 
address specified in the agreement. I have no evidence for this apart 
from the typical behaviour of lawyers and the tendency to lock down 
contact addresses in contract schedules, but it would explain what's 
being observed.


For receivers behaving this way who are subject to GDPR, there's a 
rather direct way to solve the problem: report the unsolicited 
disclosure of personal information by the receiver to the receiver's 
DPO. In some cases the DPO will be the reflexively risk-averse lawyer 
who will do anything possible to offload liability (and will therefore 
kill the receiver's participation in failure reporting), but most are 
deeply schooled in balancing interests (all processing on the 6(1)(f) 
"legitimate interests" basis requires that it be done formally; this 
would include all participation DMARC failure reporting) and will simply 
treat it as an error to fix promptly.


- Roland

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

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

Re: [dmarc-discuss] dmarc Newbie

[Roland Turner via dmarc-discuss]

Hello,

The problem that DMARC solves over the SPF -all and ADSP discardable 
mechanisms is that it allows you to see where authentication failures 
are coming from (which IP addresses) so you can fix errors/oversights 
before you disrupt legitimate email flow. The recommended action is 
therefore to review the failures and ensure that they aren't:


 * your own flows, with SPF/DKIM misconfiguration; or
 * third-party flows sent legitimately on your organisation's behalf
   (outsourced marketing functions, transactional systems, ...) but
   without appropriate authentication (generally DKIM with a different
   selector(-pair))

before you turn on p=reject.

- Roland





On 13/5/19 2:44 am, MyKonfidi Solar wrote:

Hey

Request you to suggest what exactly we are supposed to watch in th 
dmarc reports.  I had been getting all these xml files, earlier, later 
i tuned to https://dmarcanalyzer.com <https://www.dmarcanalyzer.com/>, 
and now to https://mxtoolbox.com <https://mxtoolbox.com/>. nowehere i 
am given to understand the action statement.


regards
Chetan Agrawal
India

On Fri, 10 May 2019 at 07:32, Roland Turner via dmarc-discuss 
mailto:dmarc-discuss@dmarc.org>> wrote:


Hi Andrew,

The first question is what you're seeing in the aggregate feedback
reports (Dmarcian, Agari, etc. provide the means to do this).
These should be watched for a period of time (I'd suggest weeks)
to ensure that all is well before you turn on p=reject. The most
important new capability that DMARC provides over previous
approaches is this ability to see what's happening in receiving
environments and to correct errors in your configuration (or your
understanding of how your domain is used) before you adopt a
stricter policy.

- Roland


On 10/5/19 1:55 am, Wojtowicz, Andrew via dmarc-discuss wrote:


I’m a newbie with dmarc.  I’ve been playing around with some
generators and I thought I had it setup right but found out today
one of my staff members sent out an notification email, that uses
blackboard, and it didn’t go to all gmail and yahoo users.

Saw this message in log..

SMTP error from remote mail server after pipelined end of data:
550-5.7.1 Unauthenticated email from /(My domain)/ is not
accepted due to\n550-5.7.1 domain's DMARC policy. Please contact
the administrator of\n550-5.7.1 /(My Domain)/ domain if this was
a legitimate mail. Please visit\n550-5.7.1
https://support.google.com/mail/answer/2451690
<https://support.google.com/mail/answer/2451690> to learn about
the\n550 5.7.1 DMARC initiative. z37si617489qvc.90 - gsmtp

Where can I get some help on setting up the correct dmarc dns
setting?

Thank you

Andrew Wojtowicz

Network Engineer

Tenafly Public Schools

500 Tenafly Rd

Tenafly, NJ 07670

Work - (201) 816-4555

Cell – (201) 563-9661

Email - awojtow...@tenafly.k12.nj.us
<mailto:awojtow...@tenafly.k12.nj.us>

shield logo (Custom) (2)


/NOTICE: This email message, including any attachment(s), is for
the sole use of the intended recipient and may contain
confidential and privileged information. Any unauthorized review,
use, disclosure or distribution is prohibited. If you are not the
intended recipient, please contact the sender by reply email and
destroy all copies of the original message. /

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

[Roland Turner via dmarc-discuss]

Hi Andrew,

The first question is what you're seeing in the aggregate feedback 
reports (Dmarcian, Agari, etc. provide the means to do this). These 
should be watched for a period of time (I'd suggest weeks) to ensure 
that all is well before you turn on p=reject. The most important new 
capability that DMARC provides over previous approaches is this ability 
to see what's happening in receiving environments and to correct errors 
in your configuration (or your understanding of how your domain is used) 
before you adopt a stricter policy.


- Roland


On 10/5/19 1:55 am, Wojtowicz, Andrew via dmarc-discuss wrote:


I’m a newbie with dmarc.  I’ve been playing around with some 
generators and I thought I had it setup right but found out today one 
of my staff members sent out an notification email, that uses 
blackboard, and it didn’t go to all gmail and yahoo users.


Saw this message in log..

SMTP error from remote mail server after pipelined end of data: 
550-5.7.1 Unauthenticated email from /(My domain)/ is not accepted due 
to\n550-5.7.1 domain's DMARC policy. Please contact the administrator 
of\n550-5.7.1 /(My Domain)/ domain if this was a legitimate mail. 
Please visit\n550-5.7.1 https://support.google.com/mail/answer/2451690 
 to learn about 
the\n550 5.7.1 DMARC initiative. z37si617489qvc.90 - gsmtp


Where can I get some help on setting up the correct dmarc dns setting?

Thank you

Andrew Wojtowicz

Network Engineer

Tenafly Public Schools

500 Tenafly Rd

Tenafly, NJ 07670

Work - (201) 816-4555

Cell – (201) 563-9661

Email - awojtow...@tenafly.k12.nj.us 

shield logo (Custom) (2)


/NOTICE: This email message, including any attachment(s), is for the 
sole use of the intended recipient and may contain confidential and 
privileged information. Any unauthorized review, use, disclosure or 
distribution is prohibited. If you are not the intended recipient, 
please contact the sender by reply email and destroy all copies of the 
original message. /


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

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



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

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

Re: [dmarc-discuss] newbie question about Source-IP

[Roland Turner via dmarc-discuss]

Hi Patrick,

You've posted to dmarc-discuss, a list for discussion of the DMARC 
protocol and broad interoperability issues, however your question 
relates to the OpenDMARC implementation of DMARC. You're looking for the 
OpenDMARC forum .


- Roland



On 1/3/19 6:14 am, Patrick Proniewski via dmarc-discuss wrote:

Hello,

As a followup of my previous question, I would like to get some clarification 
about Source-IP (as shown in failure reports for example).
My setup is described below:


On 26 févr. 2019, at 19:03, Patrick Proniewski via dmarc-discuss 
 wrote:

Hello,

I'm running OpenDMARC for a couple of days now on my email server. It mostly 
runs ok, but I've just got some weird failure reports.
My setup:
I run Postfix and Amavisd-new as a before queue content filter.
Policyd-SFP checks SPF on the outer SMTP and add proper authentication header.
Amavis checks DKIM and add proper authentication header.
If the mail is acceptable, Amavis handle it to the inner SMTP.

OpenDMARC can't run on outer smtp in a BQCF setup, so it runs on the inner 
SMTP. Then it sees emails coming from 127.0.0.1, no big deal because it's setup 
to trust Policyd-SFP header.
Unfortunately it looks like it does not trust Amavis' DKIM header. But I'm not 
sure about that.

../..

Sample report:

-
Feedback-Type: auth-failure
Version: 1
User-Agent: OpenDMARC-Filter/1.3.2
Auth-Failure: dmarc
Authentication-Results: my-server; dmarc=fail header.from=gmail.com
Original-Envelope-Id: 4F92A7FB1
Original-Mail-From: framalang-ow...@framalistes.org
Source-IP: 127.0.0.1 (localhost)
Reported-Domain: gmail.com
-


So, my setup impose that OpenDMARC sees only 127.0.0.1 as Source-IP. How can I 
be sure that it won't play against me? I can't understand the source code of 
OpenDMARC, so I can't be sure the verification process won't use that IP 
address, for example for SPF, even though SPFIgnoreResults is set to false.

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

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



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

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

Re: [dmarc-discuss] help!

[Roland Turner via dmarc-discuss]

Implement DKIM with as many of your third parties as possible. Most have 
now realised that they can do their own key-rotation if they simply 
specify two CNAME records for you to put into your zone file (rather 
than issue you a key, or have you issue them one). Third-party SPF will 
generally not be reliable for DMARC purposes because it will usually 
contain the service-provider's domain name rather than yours and 
therefore not align for DMARC purposes, quite apart from the problem of 
SPF record size that you've already encountered, and the maintenance 
overhead (bear in mind that you'll have to discover service-provider IP 
addresses changes by noticing failures in DMARC feedback, meaning that 
you'll need long term automated monitoring).


- Roland



On 3/12/18 1:32 pm, T Nguyen via dmarc-discuss wrote:


SPF authentication only, no dkim just yet. As domain controller owner 
we have issue with multiple third party application email senders, 
which fail specifically our spf authentication. with too many third 
party email applications that overwhelms our spf records. Since these 
application email providers generate email on behalf of their 
customers, how can they provide domain authentication to the receiving 
ends?  Appreciate all the insight.



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

[Roland Turner via dmarc-discuss]

Right. This is the envelope sender (5321.MAIL FROM). It doesn't align 
with linktechs.net, so won't contribute to a DMARC pass.


Why does the message have an author/5322.From: address in the 
linktechs.net domain, but not a valid DKIM signature? This looks like a 
typical list-breaks-DKIM scenario:


 * You're a member of the WISPA board
 * You post to bo...@wispa.org
 * The list expander sends a copy of the message back to you, with your
   email address still appearing in 5322.From:
 * But the list expander has changed the message in a way that breaks DKIM
 * The list expander does change the 5321.MAIL FROM to board-bounces,
   but SPF would have failed anyway, so this does not create a new problem
 * The message reaches linktechs.net, showing a linktechs.net
   5322.From, but with an unaligned 5321.MAIL FROM and a broken DKIM
   signature, so DMARC fails. The published policy requests rejection,
   so that's what happens.

Does this make sense?

- Roland


On 27/11/18 3:36 am, Dennis Burgess via dmarc-discuss wrote:


Nov 26 11:40:44 filter1 opendmarc[21194]: 406A610E1FC: SPF(mailfrom): 
board-boun...@wispa.org none


**

*Dennis Burgess, Mikrotik Certified Trainer *

Author of "Learn RouterOS- Second Edition”

*Link Technologies, Inc*-- Mikrotik & WISP Support Services

*Office*: 314-735-0270 Website: http://www.linktechs.net 



Create Wireless Coverage’s with www.towercoverage.com

*From:*Vladimir Dubrovin 
*Sent:* Monday, November 26, 2018 1:28 PM
*To:* Dennis Burgess ; dmarc-discuss@dmarc.org
*Subject:* Re: [dmarc-discuss] DMARC oddity


You see envelope-from (aka RFC 5321.mailfrom) address in logs, while 
DMARC checks policy against From: header (RFC 5322.From), 
envelope-from and From: may differ.


26.11.2018 22:17, Dennis Burgess via dmarc-discuss пишет:

Got an odd one, getting e-mails from another domain rejected based
on the recipients domain policy?

Nov 26 11:40:44 filter1 postfix/cleanup[63990]: 406A610E1FC:
milter-reject: END-OF-MESSAGE from
filter1.linktechs.email[127.0.0.1]: 5.7.1 rejected by DMARC policy
for linktechs.net; from=mailto:board-boun...@wispa.org>> to=mailto:dmburg...@linktechs.net>> proto=ESMTP
helo=

Nov 26 11:40:44 filter1 postfix/smtpd[64109]: <
inet:127.0.0.1:10020: 550 5.7.1 rejected by DMARC policy for
linktechs.net

Nov 26 11:40:44 filter1 postfix/smtpd[64109]: >
spam.techwebhosting.net[216.146.225.112]: 550 5.7.1 rejected by
DMARC policy for linktechs.net

Linktechs.net yes says not to accept mail form other mailserver,s
but this is a wispa.org domain that don’t have dmarc or even a SPF
record? Why does it use the to domain to lookup dmarc policy?

**

**

*Dennis Burgess, Mikrotik Certified Trainer *

Author of "Learn RouterOS- Second Edition”

*Link Technologies, Inc*-- Mikrotik & WISP Support Services

*Office*: 314-735-0270 Website: http://www.linktechs.net


Create Wireless Coverage’s with www.towercoverage.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)

--
Vladimir Dubrovin
@Mail.Ru

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

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



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

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

Re: [dmarc-discuss] DMARC is not working

[Roland Turner via dmarc-discuss]

On 23/11/18 4:01 pm, Dpto Ciberseguridad via dmarc-discuss wrote:


"v=DMARC1;p=reject;ruc=mailto:dmarc@x;

It worked fine till last month when testing emails, we saw it was not 
rejecting unauthorized emails.


Note that setting p=reject does not mean that receivers will reject 
messages from the domain that don't meet DMARC rules, it only means that 
you're requesting that receivers do so. Reasons for not doing so include:


 * Not believing that the domain registrant is competent (e.g. because
   you've published an invalid record)
 * Not believing that all non-complying messages are invalid, perhaps
   on the basis of local information.
 * Deciding to accept-and-discard instead of reject in order to avoid a
   specific failure mode with mailing lists and rejections.

Per Steven's comment, if you've not been studying (indeed, receiving) 
aggregate reports, there is a good chance that receivers can see 
legitimate email that you're unaware of and are therefore ignoring your 
request.


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

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

Re: [dmarc-discuss] LinkedIn DKIM validation failure resulting in DMARC fail

[Roland Turner via dmarc-discuss]

Ivan,

I've dug into this in the past and confirmed that there is something 
wrong that no-one seemed to want to do anything about. (I forget the 
details but (a) LinkedIn does something slightly unusual in sending its 
invitation (different envelope sender and author domains?), and (b) 
Office 365 does something odd in sending its bounce (DKIM signing for a 
Microsoft domain?))


- Roland

On 23/10/18 8:15 pm, Ivan Kovachev via dmarc-discuss wrote:

Hello all,

has anyone noticed that when LinkedIn receives 
Out-Of-Office/Automatic-Replies from domains that are fully configured 
with DKIM, LinkedIn reports that DKIM failed (signature verification 
failed) and DMARC fails?


*Scenario.*

1.LinkedIn sends invite to someone @mydomain.com 
 (hosted on Office 365 which is fully configured 
with SPF and DKIM)
2.mydomain.com  (office 365) sends an automatic 
reply back to Linkedin with empty Mail-From (because it is a bounce) 
but correctly DKIM signed.

3.LinkedIn sends forensic report back stating that DKIM failed.

*However,*
when I test the same scenario with GSuite, it verifies correctly and 
passes DMARC.


1. GSuite sends invite to someone  @mydomain.com 
 (hosted on Office 365)
2. mydomain.com  (office 365) sends an 
out-of-office reply back to GSuite with empty Mail-From (because it is 
a bounce) but correctly DKIM signed.

3. Gsuite correcly verifies the email and DKIM passes.


Does the above indicate wrong DKIM validation done at LinkedIn. Why 
would they be different? The exactly same scenario was used in both tests.


___
dmarc-discuss mailing list
dmarc-discuss@dmarc.org
http://www.dmarc.org/mailman/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] "p=none" vs. "p=quarantine; pct=0"

[Roland Turner via dmarc-discuss]

On 10/10/18 01:02, Payne, John via dmarc-discuss wrote:

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. 


It is an important characteristic of the current system that, with 
respect to message handling, p=none is semantically *identical* to 
non-existence. Were this not the case, there would be reason to be 
nervous about turning on visibility in the first place, which would 
almost certainly slow adoption.


What changes forwarders make, and why, and perhaps during which phase of 
the moon, is far, far outside the scope of the spec. These are very much 
local policy choices.


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

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

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

[Roland Turner via dmarc-discuss]

On 10/10/18 03:28, Payne, John via dmarc-discuss wrote:


p=none -> “we’re trying to figure out if we’re going to be able to go to 
p=quarantine”


While that's undoubtedly true in many cases, it's certainly not true in 
all, and the spec does not make this assumption.



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.


That's simply not true. Receivers make no representation at all that 
their handling on one day predicts their handling on the next, let alone 
what happens if other participants (domain registrants in this case) 
change something. Aggregate reports should simply reflect what actually 
happened, everything else is outside the spec.


You're making a variant of an early error that domain registrants made 
in assuming that they were somehow commanding receivers to handle 
messages in particular ways (notably to reject messages that fail 
DMARC-aligned authentication/authorisation) and were entitled to have 
other participants act in ways that suited them. A DMARC record feels 
like configuration information for receivers, but it's not. Your policy 
is merely an expression of your preference. Other system participants 
will do what suits them, just as you will. Maybe they'll tell you about 
it, maybe they won't. Hopefully they'll view unintended divergences 
between what the spec says and what they do as bugs and fix them, but 
maybe they won't, and maybe they intended them.


As pointed out elsewhere, there are inescapable dilemmas in DMARC use 
for everyone involved, so few participants will take absolute positions. 
The From:-rewrites-as-a-necessary-evil perspective means that it only 
makes sense to rewrite for p={reject,quarantine}. The "p=quarantine; 
pct=0;" approach gives you some insight into how much of the problem 
this will fix for you, with minimal risk. Sure, there will be some 
broken systems that mishandle this by overlooking pct= (no-one has yet 
offered this as an intentional choice, it is currently universally 
viewed as a bug where it arises), but as with everything else about 
DMARC, there are dilemmas everywhere.


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

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

Re: [dmarc-discuss] Hotmail violating DMARC specification

[Roland Turner via dmarc-discuss]

Calendaring corner cases are numerous. If the calendaring system is to 
co-operate with DMARC (but note that it's not a foregone conclusion that 
the operator will want to do so) the options in this case would appear 
to be:


 * Take ownership of the forwarded message by setting From: to the
   address of the person forwarding (as Outlook does with all other
   forwarding). Whether this will play nice with recipients'
   calendaring software is not clear.
 * Forward unmodified, so the original DKIM signature will still validate.

There probably aren't particularly tidy answers to this.

- Roland





On 26/09/18 00:48, Ivan Kovachev via dmarc-discuss wrote:

Hello guys,

would anyone be able to comment on the issue listed here:

https://office365.uservoice.com/forums/264636-general/suggestions/34012756-forwarding-of-calendar-appointments-from-a-dmarc-p 



I have also run some tests using a DMARC protected domain in reject 
mode and hotmail whether *manually forwarding*,*auto-forwarding* or 
*redirecting* the email treats the email in the same way and that is: 
retains the original From domain but the final recipient does the SPF 
and DKIM checks on the forwarder ie. hotmail so DMARC fails and emails 
are rejected.




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

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



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

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

Re: [dmarc-discuss] Help - updataed

[Roland Turner via dmarc-discuss]

What is a DMARC syntax error? (Which tool gave this? What operation was 
it performing at the time?)


Yes,

   example.com TXT "v=spf1 -all"
   _dmarc.example.com "v=DMARC1; p=reject;"

is a reasonable way to announce that a domain can never be used for 
sending email.


- Roland


On 26/09/18 10:04, T Nguyen via dmarc-discuss wrote:


Hi dmarc-discussing group,

Updated a few things that came to me after sending the previous message.

 1. 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.  It could be that the syntax error caused by the
receiving domain not have the text record to authorize the reports
receptions?

v=DMARC1; p=reject; pct=100; 
rua=mailto:dmarc-repo...@not-example.com,mailto:repo...@example-not.com


 2. 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. Just realized that dkim cannot be generated without a
mail server to maintain the private key.

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)

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

[Roland Turner via dmarc-discuss]

Ivan,

Can you show sample/likely envelopes/headers that would cause the 
problem? It's not clear from your description why there's a problem. Are 
you saying that Cisco is running a service that impersonates author 
(5322.From) domains of *_non_*-customers?


- Roland



On 11/07/18 19:22, Ivan Kovachev via dmarc-discuss wrote:

Hello all,

I have a question regarding third-party email encryption services and 
DMARC.


For example, when using Cisco CRES the emails contain the From domain 
of the sender and the Return-Path is that of the sender so if they 
authorize Cisco CRES then emails will pass SPF and align with regards 
to DMARC. Emails contain no DKIM signature.


The recipient then replies and again emails go through the CRES 
servers, the From domain is that of the company that replies, the 
Return-Path is also that of the company that replies, however, they 
will also have to authorize Cisco CRES in their SPF in order for DMARC 
to pass. Again no DKIM.


The problem is that there are many other email encryption services out 
there and if the sender is using any of them then their recipients 
must also authorize them in their SPF records. This means that if any 
the sender or recipient is in DMARC reject when replying to such 
emails their emails will be rejected.


Has anyone come across this problem before and what have you done to 
solved it? Is using subdomains (in DMARC none policy) for this email 
communication the only way to go for now?



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

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



--
I felt a great disturbance in the Internet, as if millions of marketers
suddenly cried out in terror and were suddenly silenced. I fear something
terrible has happened. -- Obi-Spam Kenobi, May 26, 2018

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

[Roland Turner via dmarc-discuss]

On 01/06/18 17:04, Alessandro Vesely via dmarc-discuss wrote:


I see.  As a small receiver, I didn't even think about comparing different
forwarders of the same senders.  In my case, such coincidences only cover a
handful of trusted mailing lists.  Your argument further confirms how ARC
better suits large receivers.


Not quite:

 * It confirms that mapping who to trust requires both access to and
   the ability to process a view of a large subset of the world's
   mail-servers. This is comparable to the work of cartographers in the
   physical world: you *could* drive from one end of a continent to the
   other without ever examining a map (or roadside signs prepared by
   people who had examined maps), but it would be very, very difficult.
 * It confirms that rational use of ARC by small receivers will require
   help from "cartographers", whereas big receivers are large enough to
   have their own. This sounds bad, but note that this is already true
   for SMTP anyway. Yes, you can deploy a mail-server at will, but
   securing it without the use of reputation data (typically a DNSBL)
   will be somewhere between very difficult and actually infeasible.
   Few people attempt this in practice. My guess is that if ARC turns
   out to be useful, then the reputation data required for small
   receivers to make good use of it will be readily available.



Thank you for a nice discussion


Likewise!

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

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

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

[Roland Turner via dmarc-discuss]

On 31/05/18 23:13, Alessandro Vesely via dmarc-discuss wrote:


1: Granted, the list becomes a priority list for compromise attempts

no spam indicator implies that the upstream ARC chain is faked.>>> You've lost 
me:

difficulty of substantiating statements like "I trust these guys not
to lie in ARC signing/sealing".>

This is the bit where I'm not following you. Failing to provide neighbourly
attention to the stream of mail coming out of your mail-server and failure to
accurately ARC sign appear to be orthogonal concerns. (They might be loosely
correlated to your level of diligence certainly, but are not otherwise causally
related.)

They'd better be more than loosely correlated.  If you keep them orthogonal,
you cannot make consistent assessments:

My filtering ability is visible to the people I forward to.  Although targets
don't see what I spare them, they can imagine.  If you receive spam from me,
you lower my reputation.  Easy.

OTOH, my good faith ARC signing has to be assumed.  To prove the opposite, you
start with a message I forward to you; say it ARC-claims I received it from X.
Afterwards, you need to contact X and have them deny they ever sent it.  A
rather impractical method, especially since you need an X such that you can
trust their word against mine.  How come?

Orthogonality is broken by mandating filter-before-forward.  That way,
receivers of ARC-signed, obvious spam can infer that the corresponding ARC
signature is faked.  The better the filtering, the stronger the trust, and the
more evident will a possible ARC key compromise be.  So, if you pardon my
geometry-fictional wording, the "trust not to lie in ARC signing/sealing" gets
measured by assessing its projection onto the filtering axis.


OK, I see what you're getting at (and therefore why you mentioned spam 
traps). As a [large] receiver, I would not be tackling it in this way at 
all, mostly because I don't get to ask any of the Xs what the truth is, 
but also because spam filtering and ARC signing really are largely 
orthogonal capabilities[1] (and to the extent that they're not, there's 
too much noise to make good use of the results). I would instead - to 
further extend the use of over-specified geometric analogies - be 
performing something akin to gravitational lensing:


 * For each of [tens of] thousands of domain names[2], I have from
   their email received directly an assessment of their expertise at
   ensuring that their email can be authenticated, broken down by
   stream (IP address, subnet, service provider, etc.).
 * For each forwarder, I can see how they're reporting authentication
   results for many of the same senders at the same IP addresses,
   assuming that SPF authentication results are included in ARC.
 *  From this I can determine whether the forwarder is ARC-signing
   correctly. Note that this is different to comparing the forwarder's
   probabilistic spam filtering with my own; in the ARC-signing case
   there are correct actions and incorrect actions, and a large
   receiver has enough information to tell which a forwarder is doing.


Note that none of these steps has any relationship with spam which - 
given that spammers can (and do) cause their email to authenticate, and 
legitimate senders can (and do) fail to do so - is as it should be.


- Roland

1: Yes, it is likely that forwarders who are exceptionally good at spam 
filtering will tend to be really good at ARC signing, but most of the 
important information is about forwarders who aren't exceptionally good 
at filtering, so this correlation appears largely unimportant.
2: or registrants, to the extent that this information becomes available 
again once ICANN stops arguing absurdities in front of European courts 
and focuses on the actual problem
___
dmarc-discuss mailing list
dmarc-discuss@dmarc.org
http://www.dmarc.org/mailman/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] Blind RUF and GDPR (Re: RUA vs RUF reports)

[Roland Turner via dmarc-discuss]

On 31/05/18 10:28, Richard via dmarc-discuss wrote:


Date: Thursday, May 31, 2018 09:26:38 +0800
From: Roland Turner via dmarc-discuss 

Sending failure reports to
strangers appears unjustifiable under GDPR.

A currently common case where reports are going where they shouldn't
is with mailing lists. If a list (that doesn't do rewrites) receives
a message purportedly from say yahoo (which is set to p=reject), mail
to every list member whose ESP enforces dmarc will cause a
bounce/reject potentially causing a failure report to be sent. These
list members have no relationship with yahoo, save that they are on a
list that someone sent to using a yahoo address, and have no control
over the list or ESP configuration. I can't think of a legitimate
reason for yahoo to get these reports.


Ongoing visibility of the impact of their p=reject decision seems 
reasonable, although that could readily be obtained from aggregate 
reports (and indeed more accurately, as more organisations send them).


Interdicting phishing is not relevant (where it might be if the address 
were @paypal.com).


Even understanding the mechanism of selected failures seems a fairly 
weak interest, and one that could be better pursued with private 
channels rather than ruf=.


Interesting.

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

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

[dmarc-discuss] Blind RUF and GDPR (Re: RUA vs RUF reports)

[Roland Turner via dmarc-discuss]

On 31/05/18 04:51, Jonathan Kamens via dmarc-discuss wrote:


On 5/30/18 4:22 PM, John Levine wrote:

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

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


I don't think you can be held responsible if a "total stranger's" 
email ends up in your inbox because they put your domain in the From 
line of the email without your authorization. Furthermore, of the 
cases you mentioned ("forged", "typo", "configuration error"), I don't 
think anything but "forged" happens with sufficient frequency to be 
worth your concern or the concern of the European Union's member 
states' Data Protection Authorities.




This confuses two different "total strangers" cases:

 * One is the case where a message ended up somewhere unexpected
   because someone mistyped an email address (whether in a message or
   in a DMARC DNS record).
 * One is where an email receiver is blindly sending failure reports to
   organisations unknown to them.

The former is fine as it stands, so long as the parties involved take 
responsible action with the resulting disclosures (deletion by the party 
who unexpectedly received the data - because continued processing, 
including retention, has no lawful basis - and correction of the error 
by the party who misconfigured a mail client, mistyped an address book 
entry, or mistyped a DMARC DNS record).


The latter is the important question. Sending failure reports to 
strangers appears unjustifiable under GDPR.


- Roland

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

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

[dmarc-discuss] Blind RUF and GDPR (Re: RUA vs RUF reports)

[Roland Turner via dmarc-discuss]

On 31/05/18 02:01, Jonathan Kamens via dmarc-discuss wrote:


Two comments:

1) Most of the failure reports I've seen haven't included the message 
body, they've only included the headers. So the exposure is limited. I 
assume limiting the exposure is the whole reason why the reports don't 
include message bodies.




True, however this seems like a peculiar position. Once you've 
acknowledged that limiting exposure is important, aggregate reports seem 
like a more appropriate tool.


Note that there is a compelling reason for providing message bodies, 
arguably the reason for specifying the failure reporting mechanism in 
the first place, and that's identifying phishing sites to focus 
deactivation efforts on. Doing this without an NDA would appear problematic.


2) The people receiving the failure reports aren't "total strangers." 
They are either (a) the same people who run the email infrastructure 
(if failure reports are handled internally), who are presumably 
authorized to look at email headers while troubleshooting issues, or




No. They are the people who run some other infrastructure. In the 
"volunteering failure reports without an NDA" case, they are strangers.


(b) third-party data processors (to use the GDPR terminology), which 
are permitted as long as how they are using the data is disclosed to 
users.




I think you're describing intermediaries with whom domain registrants 
contract to process their DMARC reports. These people are also strangers 
to the receivers who are sending the reports, unless they have separate 
agreements with those same intermediaries (most do, at least in the US 
and EU).


Whether or not that they are Data Processors would depend upon the 
details of those agreements. I've never read one.


There /could be/ a GDPR issue if failure reports are sent to a 
third-party processor /and/ that isn't disclosed to the user, but it 
isn't /ipso facto/ a GDPR issue to use a third-party processor to 
manage failure reports.




No. Contracting Processors does not require disclosure to Data Subjects; 
instead contractual arrangements between Controller and Processor to 
maintain the Data Subject rights and other obligations are required. 
You're thinking about disclosure to other Controllers.


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

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

[dmarc-discuss] RUF and GDPR (Re: RUA vs RUF reports)

[Roland Turner via dmarc-discuss]

On 30/05/18 22:56, Richard via dmarc-discuss wrote:


I realize that enforcement of GDPR is still a work in progress, but:

   > Failure reports send copies of your users'
   > mail to total strangers.

would seem to run directly against its intent.


I hadn't thought to perform this analysis:

 * Consent is out, unless you really want to (a) solicit voluntary
   consent from all of your users and (b) turn off failure reporting
   for those users who have yet to consent, or who have withdrawn
   consent.[1]
 * Necessity for the performance of a contract with the data subject
   would not withstand scrutiny. (Most mail services today are capable
   of operating without this; it's therefore provably not necessary.)
 * Controller's legal obligations are not relevant.
 * Data subject's vital interests are not relevant.
 * Public interest/official authority are not relevant.[2]
 * This leaves legitimate interests of the controller or a third party.

In the legitimate interests case:

1. The interest must be identified. In this case I'd suggest something
   along the lines of improving the ability of the controller (and
   mail-server operators generally) to distinguish legitimate email
   from impersonation by helping domain registrants take action to (a)
   correct configuration errors in legitimate email and (b) shut down
   impersonation, by voluntarily sending copies of messages to the
   party apparently nominated by the registrant of the domain.
2. The means must be necessary (least invasive approach possible). As
   for necessity for the performance of a contract, I'd suggest that
   this is demonstrably not true. The vast majority of DMARC's
   protection with respect to failure reports can be achieved (and as
   being achieved) by failure reports provided under NDA and by
   aggregate reports. It would be necessary to demonstrate that the
   added value of the volunteering failure reports to strangers was
   material.
3. A balancing test must be performed (interests of the controller and
   third parties vs. rights of the data subject). In particular, this
   looks at what protections are in place. I'd suggest that, at a
   minimum, this would call for data transfer agreements with
   enforceable NDA terms and data minimisation. In the latter case, if
   it is possible to perform substantially the same processing on
   anonymous data (e.g. the aggregate reports), then skipping that
   measure would be hard to defend.

More broadly, any situation in which controllers are automatically 
disclosing personal data to other controllers who are strangers to them 
would be extraordinarily difficult to justify under legitimate 
interests. Note that this is not the same situation as sending an email 
message at the request of a user, that's necessity for the performance 
of a contract.


I'd suggest that automatic sending of failure reports to strangers would 
be very difficult to justify under GDPR.


- Roland


1: There is a lot of confusion about this. Consent in GDPR terms 
(6(1)(a) and 7) means something quite different to consent in its 
contract- or common-law senses. In particular, if some other thing that 
the data subject cares about is conditioned upon that consent, or if the 
consent can't be withdrawn without the loss of some other thing that the 
data subject cares about, then it's not freely given and therefore - per 
the snappy little sentence at the end of 7(2) - didn't happen. This is 
not to say that the processing in question can't be lawful, only that 
consent can't be the legal basis. There are five other legal bases to 
explore...


2: Note that this is not a DIY thing; the interest/authority in question 
must be laid out in legislation.


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

[Roland Turner via dmarc-discuss]

On 31/05/18 02:31, Alessandro Vesely via dmarc-discuss wrote:


On Wed 30/May/2018 16:13:12 +0200 Roland Turner via dmarc-discuss wrote:

On 29/05/18 23:05, Alessandro Vesely via dmarc-discuss wrote:

[...] which includes pretty much all mail sites.  The latter is *not* a
slow-moving data set.  It grows steadily.

Steady growth *is* slow movement.

Uh?  I run a tiny mail site and get about 1.6 new domains per hour.  It is much
slower than light, but still too fast for an embedded list...  Any global
figure, anywhere?


Too fast for an embedded list certainly. As I said, "forwarding 
mail-servers more generally would then be an obvious refinement", but 
also "Even the complete set of honestly operated mail-servers in the 
world - whether forwarding or not - is changing at a rate that is still 
orders of magnitude lower than the rate of change of IP addresses used 
for abuse, consequently collecting, distributing, and using this data 
would be relatively straightforward." I took it as self-evident that I 
was describing a transition from an embedded list to a reputation data 
feed. You would presumably not attempt to list all of the IP addresses 
used for abuse in an embedded list?




1: Granted, the list becomes a priority list for compromise attempts, much as
happened with ESPs several years ago, but sudden spikes in volume can be
treated as suspicious anyway, so the benefit in compromising a small forwarder
is limited.

Spamtraps will also work well, as usual.  However, no spam indicator implies
that the upstream ARC chain is faked.  In theory, for example, ARC would allow
me to switch to forward-before-filter (maybe CPU happened to cost me more than
bandwidth, say.)  In that case, you would tend to classify me as a spammer and
possibly suspect that my keys were compromised.  How to maintain the list
remains unclear.

You've lost me:

   * If you're forwarding unfiltered email to receivers who are able to make
 good use of ARC information, and assuming that they still trust you, then
 there is no problem here: you just have lousy filters.
   * If you're forwarding to people for whom either of those things is false,
 then you're shooting yourself in the foot.

Don't be a bad neighbour: filter to the best of your ability, but don't sweat
the rest. Your neighbours are most unlikely to appreciate your dumping cost
onto them if you do otherwise.

100% agreed.  The example —admittedly somewhat stretched— was meant to
highlight the difficulty of substantiating statements like "I trust these guys
not to lie in ARC signing/sealing".


This is the bit where I'm not following you. Failing to provide 
neighbourly attention to the stream of mail coming out of your 
mail-server and failure to accurately ARC sign appear to be orthogonal 
concerns. (They might be loosely correlated to your level of diligence 
certainly, but are not otherwise causally related.)


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

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

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

[Roland Turner via dmarc-discuss]

On 30/05/18 06:09, Brandon Long via dmarc-discuss wrote:



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



I know ARC proponents don't want author's domains to sign ARC-0,
but never
understood why.  Anyway, ordinary forwarders will need to ARC sign
forwarded
messages too, which includes pretty much all mail sites. The
latter is *not* a
slow-moving data set.  It grows steadily.


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


Plenty of ordinary forwarders break DKIM:

 * Essentially all customer-controlled Exchange servers. (Office 365
   fixed this a while back for server-side rules, but this has not made
   its way into customer-controlled installations generally, or perhaps
   not even into the product.)
 * Plenty of ordinary forwarders add footers, strip attachments.
   Fortunately virus scanner spam has largely stopped.
 * Etc.

I have previously singled out MIMEsweeper for gratuitous re-encoding of 
body parts and am pleased to report that my doing so led to that problem 
being fixed. 1 down, 999 to go... Cases like this will appear as a small 
fraction of the email volume of large receivers, but require a 
disproportionately large number of fixes. It may not be 1,000, but I'm 
certain that it's hundreds.


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

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

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

[Roland Turner via dmarc-discuss]

On 29/05/18 23:05, Alessandro Vesely via dmarc-discuss wrote:


  * A single public whitelist is not necessary for ARC to work, multiple
    lists are certainly possible, but the mapping of well-behaved
    whitelist operators is:
  o much easier than mapping abusers, as the latter are seeking to
    _*evade*_ detection;
  o much slower moving (new small list operators appear at a rate of
    perhaps one per week; abusers gain control of IP addresses at a
    rate of many per second); and
  o more resilient in that possession of the abuse data by abusers
    doesn't provide a means to optimise abuse by focusing on IP
    addresses and identifiers that haven't yet been identified[1],

        meaning that a slow-moving list can be included in email
    security software, as with the current rule set for something
    like SpamAssassin.

You seem to imply that only mailing list activity needs to deploy ARC.


I hadn't meant to imply quite that, however the paragraph was already 
getting a little long so I did not elaborate further. The list operators 
would be a starting point for ARC reputation data, certainly; forwarding 
mail-servers more generally would then be an obvious refinement. Even 
the complete set of honestly operated mail-servers in the world - 
whether forwarding or not - is changing at a rate that is still orders 
of magnitude lower than the rate of change of IP addresses used for 
abuse, consequently collecting, distributing, and using this data would 
be relatively straightforward.



I know ARC proponents don't want author's domains to sign ARC-0, but never
understood why.  Anyway, ordinary forwarders will need to ARC sign forwarded
messages too, which includes pretty much all mail sites.  The latter is *not* a
slow-moving data set.  It grows steadily.


Steady growth *is* slow movement.


1: Granted, the list becomes a priority list for compromise attempts, much as
happened with ESPs several years ago, but sudden spikes in volume can be
treated as suspicious anyway, so the benefit in compromising a small forwarder
is limited.


Spamtraps will also work well, as usual.  However, no spam indicator implies
that the upstream ARC chain is faked.  In theory, for example, ARC would allow
me to switch to forward-before-filter (maybe CPU happened to cost me more than
bandwidth, say.)  In that case, you would tend to classify me as a spammer and
possibly suspect that my keys were compromised.  How to maintain the list
remains unclear.


You've lost me:

 * If you're forwarding unfiltered email to receivers who are able to
   make good use of ARC information, and assuming that they still trust
   you, then there is no problem here: you just have lousy filters.
 * If you're forwarding to people for whom either of those things is
   false, then you're shooting yourself in the foot.

Don't be a bad neighbour: filter to the best of your ability, but don't 
sweat the rest. Your neighbours are most unlikely to appreciate your 
dumping cost onto them if you do otherwise.


- Roland








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

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

[Roland Turner via dmarc-discuss]

On 28/05/18 19:26, Alessandro Vesely via dmarc-discuss wrote:


Your points define ARC's scope very well.  But what's big guys' role?

Let me call /semantic mailbox providers/ those company or personal mail sites
whose users have some kind of trust relationship with, e.g. because they work
for the company, are postmaster's friends, or whatever.  These providers can
afford to let their users transparently perceive forwarders' filtering ability,
be it naive SA deployment or sophisticated AI categorization.  They may
consider that users subscribing to mailing lists know what they do and let them
enjoy or suffer its output as-is.  "I trust these guys not to lie in From:
rewriting" could be enough for them to whitelist DMARC breakage while keeping
its anti-phishing feature, and dnswl.org would probably suffice to implement
that, if agreeing on any single public whitelist were an acceptable means to
make a protocol work.

By contrast, big guys have so many users because they offer astounding
functionalities, among which filtering is one of the most relevant.  They need
to filter forwarded messages in a manner 100% consistent with messages coming
in directly.  As you say, ARC will permit that by removing dependencies upon
upstream filtering.  I doubt anybody but big guys really needs that, but will
be glad to be confuted.


Your question was "what's big guys' role", but your argument appears to 
be the reverse:


 * That small guys can function without ARC on a hand-to-hand fighting
   basis, perhaps with the aid of third-party reputation data.
 * That big guys have a clear interest in ARC so they can project their
   filtering expertise upstream.

I'd suggest that you've therefore answered your stated question in your 
second paragraph.


For the implied question ("Why would small guys be interested?"):

 * ARC headers simply provide a view as to what happened upstream.
   Whatever effort you're willing to invest in hand-to-hand fighting is
   amplified (greater efficiency and/or effectiveness) simply by making
   use of that visibility.
 * A single public whitelist is not necessary for ARC to work, multiple
   lists are certainly possible, but the mapping of well-behaved
   whitelist operators is:
 o much easier than mapping abusers, as the latter are seeking to
   _*evade*_ detection;
 o much slower moving (new small list operators appear at a rate of
   perhaps one per week; abusers gain control of IP addresses at a
   rate of many per second); and
 o more resilient in that possession of the abuse data by abusers
   doesn't provide a means to optimise abuse by focusing on IP
   addresses and identifiers that haven't yet been identified[1],

   meaning that a slow-moving list can be included in email
   security software, as with the current rule set for something like
   SpamAssassin.

- Roland

1: Granted, the list becomes a priority list for compromise attempts, 
much as happened with ESPs several years ago, but sudden spikes in 
volume can be treated as suspicious anyway, so the benefit in 
compromising a small forwarder is limited.


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

[Roland Turner via dmarc-discuss]

Al,

Note that the terminology changed a while back from forensic reports to 
failure reports, presumably to remove the confusion that the use of the 
term forensic invites[1].


You've not stated what action you intend to take in response to the 
receipt of a failure report, so it's a little difficult to answer your 
question, but I'd point out two things:


 * Very few receiver-side authentication failures will cause you
   receive a failure report merely in response to your setting a ruf
   parameter. Receivers are in general unwilling to send them blindly,
   most will want background checks of the requester and a formal NDA,
   both of which generally happen as part of the contract with a
   specialist organisation providing email-authentication-related
   services. The spec provides for an interoperable failure reporting
   mechanism, but [obviously] can't mandate its use. If you are
   interested in knowing about failures in order to take some action
   (e.g. to change how you use particular lists, or to identify a list
   operator to encourage to change their DMARC handling), then >90% of
   the information that you're looking for is exclusively available to
   you in the aggregate reports.
 * For domains where you've not yet switched on p=reject, e.g. to
   minimise disruption of email flow, knowing about third parties
   impersonating you may be relevant whether or not they're sending to
   the few receivers who will send failure reports on request. This was
   certainly the case for me; when it became clear through aggregate
   reports that my personal domain was being impersonated - despite my
   not receiving a single failure report - I elected to switch on
   p=reject, then set about encouraging the few list operators who
   weren't yet honouring it to do so.

This does mean having to put in place some means to monitor aggregate 
reports for interesting failures, yes. Processing the XML to discover 
this is pretty straightforward, so long as you avoid the usual risks in 
processing XML from untrusted sources.


- Roland

1: working out what happened before vs. suitability for presentation in 
a public forum, particularly a court of law




On 28/05/18 01:17, Al Iverson via dmarc-discuss wrote:

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

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

[Roland Turner via dmarc-discuss]

On 25/05/18 19:00, Alessandro Vesely via dmarc-discuss wrote:


Wasn't this tried for SPF already?


A whitelist of "I trust these guys to make exactly the same 
abuse-filtering decisions that I'd make" and a whitelist of "I trust 
these guys not to lie in ARC signing/sealing" are two very different things:


 * The former is somewhat imaginary and generally devolves to "I trust
   these guys to filter abuse at or better than my ability to do so",
   which essentially means a handful of big guys.
 * The latter could readily include every existing mailing list
   operator, and add new ones with minimal fuss.

Your question is a bit like asking whether DMARC p=reject hadn't been 
tried for ADSP already. In both cases yes, but with the addition of a 
small but vital component (feedback in DMARC's case, no dependence upon 
upstream filtering in ARC's case) that has the potential to immensely 
alter the outcome.



Assuming, for the sake of argument, that such a whitelist will be ready right
after ARC's availability, by that time most mailing lists will have adjusted
their From: rewriting so as to work smoothly with DMARC.  Hence, by the "If it
ain't broke, don't fix it" principle, I see no likely looking mass adoption of
ARC+whitelist.  What am I missing?


From the viewpoint of a lot of people[1], list handling very broken at 
present. Also, the thousands of small forwarding cases which break DKIM 
aren't ever likely to be fixed because in each case doing so would break 
someone's expectation. ARC creates no dilemmas (contrast asserting or 
honouring -all, o=-, discardable, or even p=reject), but allows the vast 
majority of the small forwarding cases to be fixed, and mailing list 
behaviour to be restored to its traditional form.


I do take your point that there's a fait accomplis risk, but I suspect 
that there's enough residual pain on both fronts (indignation at 
currently necessary list behaviour, smaller forwarding cases that just 
break) that ARC's deployment will proceed. Whether we'll get to the 
point where all MTA vendors recommend that ARC-signing be turned on 
unconditionally (and the associated DNS gymnastics performed) is an open 
question.


- Roland

1: I don't share this viewpoint, but accept it as a legitimate concern.
___
dmarc-discuss mailing list
dmarc-discuss@dmarc.org
http://www.dmarc.org/mailman/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 newbie, seems to work, so why this report?

[Roland Turner via dmarc-discuss]

Gerben,

Note that the HELO string is only ever processed for DMARC if MAIL FROM 
is <> and, even then, not all implementations process it at all (it's 
dependent upon the behaviour of the underlying SPF implementation).


The  tag is telling you that the return path is 
{something}@mail.mydomain.tld [1]


dumbledore.mydomain.tld tells you that the 
From: header contains {something}@dumbledore.mydomain.tld, not the HELO 
string or MAIL FROM domain.


Generally this means that the program that generated the message used 
this domain and your MTA simply passed it through.


- Roland

1: or the return path is <> and the HELO string is mail.mydomain.tld, 
and Yahoo!'s SPF implementation reports that to DMARC




On 18/05/18 21:39, Gerben Wierda via dmarc-discuss wrote:
I’m setting up DMARC for my mail server. I tried sending a mail to an 
account on the icloud.com  domain (which reports 
DMARC) and there I see:


Received-Spf: pass (mr21p00im-spfmilter004.me.com 
: domain of myn...@mydomain.tld 
 designates XXX.XXX.XXX.XXX as permitted 
sender) receiver=mr21p00im-spfmilter004.me.com 
; client-ip=XXX.XXX.XXX.XXX; 
helo=mail.mydomain.tld; envelope-from=myn...@mydomain.tld 


X-Dmarc-Info: pass=pass; dmarc-policy=none; s=r1; d=r0
X-Dmarc-Policy: 
v=DMARC1;p=none;sp=quarantine;pct=100;rua=mailto:dm...@mydomain.tld,mailto:re+vghcolsq...@dmarc.postmarkapp.com
Received: from mr11p00im-smtpin012.mac.com 
 ([17.110.69.200]) by 
ms20524.mac.com  (Oracle Communications 
Messaging Server 8.0.1.3.20170906 64bit (built Sep  6 2017)) with 
ESMTP id <0p8x00kcde2dm...@ms20524.mac.com 
> for myn...@icloud.com 
; Fri, 18 May 2018 13:13:25 + (GMT)
Received: from mail.mydomain.tld (mail.mydomain.tld [XXX.XXX.XXX.XXX]) 
by mr11p00im-smtpin012.me.com  
(Oracle Communications Messaging Server 8.0.1.2.20170607 64bit (built 
Jun  7 2017)) with ESMTPS id 
<0p8x00h3ve2al...@mr11p00im-smtpin012.me.com 
> for 
myn...@icloud.com  (ORCPT myn...@icloud.com 
); Fri, 18 May 2018 13:13:24 + (GMT)
Received: from localhost (localhost [127.0.0.1])by mail.mydomain.tld 
(Postfix) with ESMTP id 57F0B261CB53for >; Fri, 18 May 2018 15:13:21 +0200 (CEST)
Received: from mail.mydomain.tld ([127.0.0.1]) by localhost 
(dumbledore.mydomain.tld [127.0.0.1]) (amavisd-new, port 10024) with 
ESMTP id b6L6g5ttGPiH for >;Fri, 18 May 2018 15:13:19 +0200 (CEST)
Received: from [192.168.169.103] (d4b27fea.static.ziggozakelijk.nl 
 [212.178.127.234])by 
mail.mydomain.tld (Postfix) with ESMTPSA id 057A3261CB45for 
>; Fri, 18 May 2018 
15:13:18 +0200 (CEST)


But I also got an aggregate report from Yahoo that suggests something 
is wrong:





Yahoo! Inc.
postmas...@dmarc.yahoo.com 


1526605741.475970

1526515200
1526601599 



mydomain.tld
r
r
none
100



XXX.XXX.XXX.XXX
1

quarantine
fail
fail



dumbledore.mydomain.tld




neutral


mail.mydomain.tld
none





This seems to suggest that Yahoo received an email from my MTA at IP 
address XXX.XXX.XXX.XXX (which is the correct IP of mail.mydomain.tld) 
but the header was dumbledore.mydomain.tld. Is that correct? That is 
weird, because my mail server is set to use 'helo mail.mydomain.tld'. 
So, apparently, it seems some program on my server is trying to send 
mail to a yahoo MTA bypassing my mail server, correct? If so, it is an 
unexpected catch. But I need to know if it is correct.


Thanks in advance

Gerben


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

[Roland Turner via dmarc-discuss]

Would this really help?

You haven't explained what you mean by "a little hard to consume". On 
the face of it, it's just an integer; a 1 is no easier to perform 
arithmetic on than a 2,436. If what you mean is that it's difficult to 
make meaningful comparison between the number that you send and the 
number reported received then that's true of course, but that would 
remain the case as you'd have no way to work out which of the counts in 
the individual receiver reports included messages that had been 
processed by mailing lists; you'd replace your 2,436 with an 
indeterminate number between 1 and, say, 100.


- Roland


On 05/05/18 03:37, Scott Kitterman via dmarc-discuss wrote:

I participate in a lot of mailing lists many of which that have a large number
of subscribers.  As a result, when I send a single message to a mailing list,
many copies of the same message get sent to users at large mail providers.
These get counted as individual messages in aggregate reporting.

As an example, I have been able to find four messages I sent to
lists.debian.org email lists on April 30th.  The volume reported for that
source for that day from various feedback reporters was 2,436.  This makes it
a little hard to consume the feedback.

Shouldn't it be possible to de-duplicate these based on message ID before
sending aggregate reports back?  Can/should this be added to DMARC the next
time the specification is updated?

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

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



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

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

Re: [dmarc-discuss] Multiple DKIM Signature Reporting in DMARC

[Roland Turner via dmarc-discuss]

On 01/05/18 06:47, Brandon Long via dmarc-discuss wrote:

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


This is beginning to feel like "what parts of Authentication-Results 
should appear in ?".


Does it make sense to:

 * Add header.{a,c,s} to
   
https://www.iana.org/assignments/email-auth/email-auth.xhtml#email-auth-methods
 * Add corresponding element definitions to 

?

(Is this over-engineering?)

- Roland




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


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

Re: [dmarc-discuss] Mimecast and Office 365

[Roland Turner via dmarc-discuss]

eged. It is intended solely for use by 
*rol...@rolandturner.com * and others authorized to receive it. If you 
are not *rol...@rolandturner.com * you are hereby notified that any 
disclosure, copying, distribution or taking action in reliance of the 
contents of this information is strictly prohibited and may be unlawful.


This email message has been scanned for viruses by Mimecast. Mimecast 
delivers a complete managed email solution from a single web based 
platform. For more information please visit http://www.mimecast.com




*From: *dmarc-discuss <dmarc-discuss-boun...@dmarc.org> on behalf of 
Roland Turner via dmarc-discuss <dmarc-discuss@dmarc.org>

*Reply-To: *Roland Turner <rol...@rolandturner.com>
*Date: *Thursday, 12 April 2018 at 09:07
*To: *"dmarc-discuss@dmarc.org" <dmarc-discuss@dmarc.org>
*Subject: *Re: [dmarc-discuss] Mimecast and Office 365

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




___
dmarc-discuss mailing list
dmarc-discuss@dmarc.org
http://www.dmarc.org/mailman/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] [EXTERNAL] Re: Mimecast and Office 365

[Roland Turner via dmarc-discuss]

Ah, in that case we've been talking at crossed purposes. I've just 
realised that Ivan's question ("Would O365 do DMARC checks for internal 
emails ie. O365 tenant employee to another O365 tenant employee?") is 
ambiguous:


 * I've assumed that he means: Would O365 do DMARC checks for internal
   emails ie. O365 tenant employee to (another O365 tenant) employee?",
   i.e. an employee of another tenant
 * You've assumed that he means: Would O365 do DMARC checks for
   internal emails ie. O365 tenant employee to another (O365 tenant
   employee)?", i.e. another employee of the same tenant

Ivan, if you're still following, which question are you asking?

- Roland





On 24/04/18 13:53, Terry Zink via dmarc-discuss wrote:

Okay, when I say "internal mail" I mean intra-tenant mail. Inter-tenant mail is 
basically the same as external mail from a customer perspective.

-Original Message-
From: Roland Turner 
Sent: Monday, April 23, 2018 9:58 PM
To: Terry Zink ; dmarc-discuss@dmarc.org
Subject: [EXTERNAL] Re: [dmarc-discuss] Mimecast and Office 365

On 24/04/18 00:51, Terry Zink via dmarc-discuss wrote:


Failure reporting seems odd (because it's always legitimate) until
you recall that part of the purpose of failure reporting is to
discover errors by the domain registrant, particularly
including errors in the DNS zone file, which may or may not
be under Office 365 control

If Office 365 isn’t doing any DNS checks for SPF, DKIM, and DMARC for
internal email, then how would a DMARC report help with any of that?


On this line of reasoning, it would be necessary to perform those checks during 
message handling.

(I note that you refer here to "internal mail" and below to "inter-tenant 
communication". To be clear, I'm referring specifically to DMARC reporting - both failure and 
aggregate - for inter-tenant email, rather than for intra-tenant email.)

Aggregate reporting likewise seems like something that would make
sense for inter-tenant communication

Inter-tenant communication is treated the same (more or less) as an
inbound message that originates from outside the service, so any DMARC
reports that are sent would not different between tenant-to-tenant
mail vs. outside-to-Office365 mail.


So long as the checks are being performed, yes, this is what I'm suggesting.

You might reasonably object that the incremental benefit in performing these 
tests is too small to warrant performing them of course (presumably there are 
no large mailing-list operators using Office 365).


Does Office 365 DKIM sign inter-tenant email?

Yes. Inter-tenant mail is treated the same for DKIM purposes as
Tenant-to-external mail. Our customer guidance is here for DKIM:
https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Ftechn
et.microsoft.com%2Fen-us%2Flibrary%2Fmt695945(v%3Dexchg.150).aspx
=02%7C01%7Ctzink%40microsoft.com%7Cabbbe14f6bb34e45729108d5a9a007be%7C
72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636601427147563145=q0
XGyDUlS9dz9n25T5IrxtsbzyX6FIXTstxD7ZI0Exw%3D=0


Great.

- Roland


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

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



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

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

Re: [dmarc-discuss] Mimecast and Office 365

[Roland Turner via dmarc-discuss]

On 24/04/18 00:51, Terry Zink via dmarc-discuss wrote:


> Failure reporting seems odd (because it's always legitimate)
> until you recall that part of the purpose of failure reporting
> is to discover errors by the domain registrant, particularly

> including errors in the DNS zone file, which may or may not

> be under Office 365 control

If Office 365 isn’t doing any DNS checks for SPF, DKIM, and DMARC for 
internal email, then how would a DMARC report help with any of that?




On this line of reasoning, it would be necessary to perform those checks 
during message handling.


(I note that you refer here to "internal mail" and below to 
"inter-tenant communication". To be clear, I'm referring specifically to 
DMARC reporting - both failure and aggregate - for inter-tenant email, 
rather than for intra-tenant email.)


> Aggregate reporting likewise seems like something that would
> make sense for inter-tenant communication

Inter-tenant communication is treated the same (more or less) as an 
inbound message that originates from outside the service, so any DMARC 
reports that are sent would not different between tenant-to-tenant 
mail vs. outside-to-Office365 mail.




So long as the checks are being performed, yes, this is what I'm suggesting.

You might reasonably object that the incremental benefit in performing 
these tests is too small to warrant performing them of course 
(presumably there are no large mailing-list operators using Office 365).



> Does Office 365 DKIM sign inter-tenant email?

Yes. Inter-tenant mail is treated the same for DKIM purposes as 
Tenant-to-external mail. Our customer guidance is here for DKIM: 
https://technet.microsoft.com/en-us/library/mt695945(v=exchg.150).aspx




Great.

- Roland

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

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

Re: [dmarc-discuss] Mimecast and Office 365

[Roland Turner via dmarc-discuss]

DMARC checking within a service provider doesn't make much sense, 
however DMARC reporting probably would when/if you implement it:


 * Failure reporting seems odd (because it's always legitimate) until
   you recall that part of the purpose of failure reporting is to
   discover errors by the domain registrant, particularly including
   errors in the DNS zone file, which may or may not be under Office
   365 control.
 * Aggregate reporting likewise seems like something that would make
   sense for inter-tenant communication.

Related question: does Office 365 DKIM sign inter-tenant email? (This 
would not be terribly important for end delivery at the addressed 
tenant, but would be important for messages that were automatically 
forwarded elsewhere.)


- Roland


On 23/04/18 12:55, Terry Zink via dmarc-discuss wrote:


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

I didn’t see this answered, so answering it now.

Office 365 doesn’t do DMARC checks for internal emails since they 
don’t leave the network perimeter. Since no DMARC check is done, no 
DMARC report is sent (Office 365 doesn’t send DMARC reports anyway, 
but if it did, it wouldn’t in this case). There are some advanced 
reporting capabilities for Advanced Threat Protection customers that 
can quasi-approximate DMARC reports, and you could use Transport rules 
in the service to approximate a RUF report. But there’s no official 
DMARC reporting at this time.


--Terry

*From:*dmarc-discuss <dmarc-discuss-boun...@dmarc.org> *On Behalf Of 
*Roland Turner via dmarc-discuss

*Sent:* Thursday, April 12, 2018 12:57 AM
*To:* dmarc-discuss@dmarc.org
*Subject:* [EXTERNAL] Re: [dmarc-discuss] Mimecast and Office 365

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



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

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



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

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

Re: [dmarc-discuss] Multiple DKIM Signature Reporting in DMARC

[Roland Turner via dmarc-discuss]

On 21/04/18 05:36, Scott Kitterman via dmarc-discuss wrote:


As most of you already know, the DCRUP working group is adding a new signature
algorithm to DKIM.  I have been sending dual rsa-sha256/ed25519-sha256 signed
mail for some time and I have notice an oddity in DMARC reporting.

Typically, I'll see something like this XML snippet:



kitterman.com
pass
201803r


kitterman.com
fail
201803e


The first one is the rsa-sha256 signature and the second, marked fail, is the
ed25519-sha256 signature (I can tell based on the selector).  In all cases
I've checked, the correct (DMARC pass) result was obtained, but I don't think
this is the best way to report it.


It would be helpful for the receiver to explain that the problem is an 
interoperability one rather than an asserted failure of an implemented 
algorithm, certainly.



RFC 6376 says:


3.3.4.  Other Algorithms

Other algorithms MAY be defined in the future.  Verifiers MUST ignore
any signatures using algorithms that they do not implement.

I'm not sure reporting a failure is consistent with "MUST ignore".  In any
case, I think it would be useful to distinguish between DKIM evaluation failed
and not evaluated due to unknown algorithm in DMARC reporting.


There are half a dozen things which must be ignored if not supported 
(canonicalisations, etc.), but the obligation to ignore doesn't appear 
to imply an obligation not to report by whatever means are appropriate, 
only that the ignored elements must be removed from consideration prior 
to computing a pass.


More directly, in 6.3 Interpret Results/Apply Local Policy:


If the email cannot be verified, then it SHOULD be treated the same
as all unverified email, regardless of whether or not it looks like
it was signed.


This would appear to encourage treating 3.3.4 cases in the same way as 
all unverified email, i.e. reporting a fail, as the example you quote 
does. I do note that RFC 7601 - whose results RFC 7489 uses - 
establishes separate criteria for none, fail, policy, and neutral. It 
might be argued that neutral is a better fit for reporting the use of a 
signature algorithm not supported by the verifier:


   none:  The message was not signed.

   pass:  The message was signed, the signature or signatures were
  acceptable to the ADMD, and the signature(s) passed verification
  tests.

   fail:  The message was signed and the signature or signatures were
  acceptable to the ADMD, but they failed the verification test(s).

   policy:  The message was signed, but some aspect of the signature or
  signatures was not acceptable to the ADMD.

   neutral:  The message was signed, but the signature or signatures
  contained syntax errors or were not otherwise able to be
  processed.  This result is also used for other failures not
  covered elsewhere in this list.


Would using neutral with some explanatory text in a human_result element 
suit, or would you advocate the addition of "unsupported" (or similar) 
to 7601 and 7489?


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

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

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

[Roland Turner via dmarc-discuss]

As they're purely internal to a single organisation (the receiving 
domain, which happens to have outsourced to Mimecast and Microsoft), 
there's no reason to record the failures but, yes, 
Authentication-Results: headers might reasonably be expected to contain 
this information. ARC headers also as they start to appear.


- Roland



On 19/04/18 01:36, Al Iverson via dmarc-discuss wrote:

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

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

[Roland Turner via dmarc-discuss]

On 19/04/18 00:48, Ivan Kovachev via dmarc-discuss wrote:


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.


This is a neat feature: why require customers to separately configure 
trusted relays when they've already voted with their MX records?


Only the perimeter (i.e. MX) system - or set of systems under the same 
administrative control - should be enforcing DMARC:


 * SPF will always be broken for a downstream system (because it will
   see the IP address of the upstream system)
 * DKIM will potentially be broken by the upstream system (always in
   Mimecast's case)

Reporting is probably a no also, because there's no reason at all for 
Microsoft to disclose this information; from the perspective of the 
email system the Mimecast->Microsoft transition is an internal step. Are 
you looking for such reporting to occur?


- Roland

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

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

Re: [dmarc-discuss] Mimecast and Office 365

[Roland Turner via dmarc-discuss]

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
___
dmarc-discuss mailing list
dmarc-discuss@dmarc.org
http://www.dmarc.org/mailman/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 treat multiple DMARC reports for the same message

[Roland Turner via dmarc-discuss]

Hi Ivan,

There is in general no way to identify multiple DMARC reports for the 
same message[1]. The spec is simply pointing out that DMARC report 
consumers cannot assume things like aggregate message counts across 
reports from multiple receivers indicate that same number of original 
messages. For example, it would be incorrect to tell a domain registrant 
that of the 22,513 messages sent (information obtained by some means 
other than DMARC), the 18,514 reported in DMARC reports indicates that 
82.2% of messages bearing that From: domain are reaching receivers who 
provide DMARC feedback.


- Roland

1: As an existence proof: you could send each message with its own 
unique RFC 5322 From: domain as "From: User 
", in which case you'd be able to pair 
up related reports. This almost certainly isn't a good idea.




On 23/02/18 18:53, Ivan Kovachev via dmarc-discuss wrote:

Hello all,

in section 9.3 of the ARC RFC it says:

"Mediators SHOULD generate DMARC reports on messages which 
transit their system just like any other message which they receive. 
This will result in multiple reports for each mediated message as they 
transit the series of handlers. DMARC report consumers should be aware 
of this behaviour and make the necessary accommodations."



Could someone please advise how to identify multiple DMARC reports for 
the same message and display a single final result instead of multiple 
results for the same message (from the perspective of DMARC report 
consumers)?



___
dmarc-discuss mailing list
dmarc-discuss@dmarc.org
http://www.dmarc.org/mailman/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] DSN from microsoftonline.com

[Roland Turner via dmarc-discuss]

On 21/12/17 05:43, A. Schulze via dmarc-discuss wrote


Am 20.12.2017 um 18:44 schrieb Roland Turner via dmarc-discuss:

What HELO/EHLO hostname is being presented?

I'm out of office for the next days and have no access to that data.
 From what I remember it's the hostname of the sending system, a rDNS related 
to Microsoft.

Why do you think, the EHLO is important?

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

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



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

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

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

[Roland Turner via dmarc-discuss]

On 21/12/17 05:43, A. Schulze via dmarc-discuss wrote:


Am 20.12.2017 um 18:44 schrieb Roland Turner via dmarc-discuss:

What HELO/EHLO hostname is being presented?

I'm out of office for the next days and have no access to that data.
 From what I remember it's the hostname of the sending system, a rDNS related 
to Microsoft.

Why do you think, the EHLO is important?


SPF tests both:

 * the domain in the email address provided in MAIL FROM; and
 * the hostname provided in HELO/EHLO

in part to deal intelligently with the empty return paths used in 
automated notifications of non-delivery, delivery-status, and delivery.


I doubt that this will solve your problem, but note that your assertion 
that SPF could never been aligned wasn't supported by the information 
that you quoted.


The actual answer to your problem will therefore turn on DKIM. Have you 
explored whether the organisations whose DSNs are failing DMARC also 
have the rest of their email failing DMARC? The use of the 
${customer}.onmicrosoft.com domain to sign is consistent with domains 
for which DKIM signing hasn't been turned on. (It could also be a 
DSN-handling bug of course.)


- Roland

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

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

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

[Roland Turner via dmarc-discuss]

What HELO/EHLO hostname is being presented?

- Roland



On 20/12/17 21:14, A. Schulze via dmarc-discuss wrote:


Hello,

we use to send a portion of messages requesting delivery status 
notification on success.
In general DSN messages tend to not pass DMARC very often, but as we 
request DSN on success explicit

we monitor them.

Now I noticed a pattern on DSN sent from Microsoft.

RFC5321.MailFrom <>
RFC5322.From 
DKIM-Signature   d=${customer}.onmicrosoft.com

SPF could never be aligned and DKIM isn't aligned.

$ opendmarc-check microsoftonline.com
DMARC record for microsoftonline.com:
    Sample percentage: 100
    DKIM alignment: relaxed
    SPF alignment: relaxed
    Domain policy: none
    Subdomain policy: quarantine
    Aggregate report URIs:
    mailto:d...@rua.agari.com
    Failure report URIs:
    mailto:d...@ruf.agari.com

Any subdomain use p=quarantine but any DSN systematically fail.
Is this intentional?

Andreas




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

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



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

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

Re: [dmarc-discuss] Google not sending aggregate reports for my .US TLD

[Roland Turner via dmarc-discuss]

On 28/10/17 06:55, Dave Crocker via dmarc-discuss wrote:

There's a meta-lesson here, given how relatively mature and 
heavily-used DMARC is, which ought to make it surprising that this 
sort of thing pops up this late.


But I can't figure out what sort of productive statement to make to 
describe the lesson or what to do about it...


Guidance to receivers (is there any?) might be expanded to encourage 
observance of Postel's law. Even if receivers wish to take the "we're 
doing you a favour" perspective or the "we don't want to enable still 
more broken software" perspective and therefore not accommodate domain 
registrants with invalid DMARC records, they might consider a courtesy 
note where a record exists that is clearly an attempt at a legitimate 
record (rather than an artefact of some other malfunction) but is not 
correct enough to permit reliable automated processing.


The meta-lesson might simply be to bear Postel's law in mind when 
drafting standards and guidance: take for granted that there will be 
invalid messages/records/etc. out there and think through up front what 
to do with them. In request/response protocols it's straight-forward: 
return an error. In cases where information in published for 
asynchronous automated consumption, it probably needs to be thought 
through on a case-by-case basis.


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

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

Re: [dmarc-discuss] DMARC authentication issues with Google

[Roland Turner via dmarc-discuss]

Is the information in this graph consistent with what's in Google's 
aggregate feedback? (This is to determine whether Google's DMARC 
implementation is broken, or just the postmaster tool.)


- Roland


On 05/10/17 18:51, The Venus Project Postmaster via dmarc-discuss wrote:


Hi everyone,

For the past several months we have been experiencing ups and downs in 
our DMARC authentication with Gmail, as seen from Google's postmaster 
tool (see attached screenshot). DKIM and SPF authentication are 
consistently at 100%, but DMARC authentication varies wildly, although 
there have been no configuration changes on our side.


Our DMARC DNS record seems to be set up properly.

Some time ago I contacted the Google postmaster team through their 
feedback form, but nothing followed.


Does anyone have any suggestions on what could be causing this (could 
it be anything on our end?) and what we could do to resolve it?


Thanks in advance,
Borislav
The Venus Project Postmaster Team
www.thevenusproject.com 



___
dmarc-discuss mailing list
dmarc-discuss@dmarc.org
http://www.dmarc.org/mailman/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] Anything to be done about DMARC failures caused by internal Microsoft forwards?

[Roland Turner via dmarc-discuss]

On 16/07/17 09:07, Jonathan Kamens via dmarc-discuss wrote:

my impression that DMARC is unreliable because of problematic elements 
scattered throughout its design and implementation. 


DMARC is only "unreliable" if you start with unrealistic expectations. 
The idea that domain registrants get to tell receivers what to do with 
email, or even to require them to provide feedback, is pretty obviously 
absurd. DMARC permits domain registrants to request these things and - 
to the extent the receivers are willing - to receive feedback.


Of necessity, DMARC reflects the email environment as it is, rather than 
an idealised form of it. As in so many other contexts, once the lights 
come on, the rough edges become visible.


That DMARC is being peddled by some as the current FUSSP is unfortunate, 
but that doesn't invalidate DMARC, only the positions of those who are 
doing this.


Simply put, I want to make it more likely that legitimate emails from 
our domain will be delivered,


DMARC p=none helps indirectly by providing a means for you to discover 
DNS/MTA issues under your control, and therefore to promptly fix them. 
Obviously this requires automatic monitoring and alerting of feedback, 
exactly because you aren't likely to read XML reports day in and day out 
indefinitely.


and more likely that forged emails purporting to be from our domain 
will be rejected. 


This remains available, although as you've noticed it comes at a cost:

We do not have enough of a problem with forged emails that I am 
willing to do anything that will cause legitimate emails that have 
been accepted in the past to start being bounced because of DMARC.




That's a really important decision. p=none is therefore the only option 
that makes sense for you to use.



  * Reviewing DMARC aggregate reports by hand -- i.e., just loading
the XML files into a text editor and searching them for potential
problems -- on an ongoing basis is far too time-consuming to be
sustainable. Instead, you can skip getting the reports; or you can
file the reports in a separate folder and only look at them when
you're investigating a known delivery issue; or you can feed the
reports through a service like dmarcian and review them there.



Most of the available value comes from automated monitoring over an 
extended period but, yes, I also simply accumulate aggregate reports for 
reactive diagnosis in some cases.



  * Not everybody who pays attention to DMARC records generates
aggregate reports. Not everybody who pays attention to DMARC
records generates failure reports. It's entirely possible that
some legitimate emails from us will be rejected due to DMARC
failures without my finding out that's happening until much later,
if at all.



Yes. Most of these issues were apparent to me when I first saw DMARC 
presented at MAAWG. I therefore asked, and the response was that some 
feedback is better than no feedback and that some implementation of 
proposed disposition was better than none. That has been the guiding 
principle from the outset and, pretty clearly, is the only way this can 
work. DMARC is not a piece of software that you install and run in a 
closed system that you control, it's a series of requests to third 
parties who have a range of higher and/or conflicting priorities.


The idea that DMARC is bad because it doesn't give perfect feedback or 
perfect control rather misses the point.


  * There is no on-ramp for DMARC that will allow me to know with
certainty what the impact of DMARC will be before it starts
causing some legitimate emails to be bounced. Though the DMARC
spec tries to create such an on-ramp, the way email providers
interpret DMARC in real life is quirky and highly variable from
provider to provider.



DMARC does not attempt to create on-ramp that gives you certainty. It 
does do various things to ease transition, certainly. For contrast, 
compare SPF -all (even if you're willing to field an instrumented DNS 
server), DomainKeys o=-, and ADSP discardable. In each case, domain 
registrants employing these mechanisms were essentially shooting 
blindly, unless they were large enough to maintain (or pay for the use 
of) seed boxes. DMARC's reporting mechanism profoundly changed that 
situation, and is arguably the primary reason that it succeeded where 
e.g. ADSP did not. (There were also some important differences in 
development process that were relevant.)



  o One example of this is the fact that although one would think
that "p=none pct=100" and "p=reject pct=0" would have exactly
the same practical effect, in fact they behave differently at
some sites.



I assume that you mean _p=quarantine; pct=0_; . _p=reject; pct=0;_ is 
supposed to behave differently.


This is a neat hack that breaks the principle of pct=0, however it does 
so in a way which benefits domain registrants, so is hardly a problem. 
The great concern 

Re: [dmarc-discuss] Get failure reports without actually rejecting messages?

[Roland Turner via dmarc-discuss]

Hi Jonathan,

Your thesis is incorrect: there is no connection between your specified 
policy and whether you'll receive failure reports. Very few receivers 
are willing to send failure reports so, in general, you won't receive 
them. There are some situations in which they are made available under 
NDA, but I'd suggest that that's generally only relevant for the largest 
senders in the world.


This does mean that you have imperfect information available on the 
basis of which to decide whether to switch to p=(quarantine|reject).


I would point out one useful detail which is relevant if your concern is 
corporate email (rather than bulk): because of the traditional handling 
of discussion lists (mailing lists in which subscribers may also post, 
like this one), some list providers will alter the From: header for 
messages from p=(quarantine|reject) domains, which means that p=none 
results will be slightly worse than they should be. To explore this, set 
"p=quarantine; pct=0". This is the same policy as p=none (because the 
100% that fall back will fall back to none), but is enough to trigger 
the From: change in some cases, particularly Google Groups.


- Roland



On 12/07/17 10:45, Jonathan Kamens via dmarc-discuss wrote:


We've recently started using DMARC for our domain, and we're doing our 
best to get everything passing before we switch from p=none to 
p=reject. Unfortunately, the information we're getting from the 
aggregate reports that various domains are sending us is not always 
sufficient for us to figure out DMARC failures. We thought we could 
address this by putting an "ruf" field into our DMARC record, but 
after doing that, we're still not getting any failure reports. After 
further research, I think this is because failure reports aren't 
actually generated for p=none, i.e., they're only generated for p=reject.


Is that correct? If so, that seems like a real problem that I don't 
know how to get past. Here's the thing... I'm pretty sure most of the 
DMARC failures we're seeing are actually legitimate email messages, 
but like I said, we don't have enough information from the aggregate 
reports to be able to figure out why they're failing DMARC. There's a 
chicken-and-egg problem here: I can't get enough information to figure 
out what's going wrong with these emails until I enable p=reject, and 
because I don't want to bounce legitimate emails, I can't enable 
p=reject until I've figured out what's going wrong with these emails. 
So, what am I supposed to do?


Also, another thing I'm confused about from reading the available 
information about DMARC is whether, once we enable p=reject, we'll get 
copies of /all/ messages that are rejected due to DMARC failures, or 
whether instead it's up to the discretion of each receiving MTA to 
decide whether to generate a failure report. If the former, then at 
least theoretically, we could enable p=reject briefly, collect some 
sample DMARC failure reports to troubleshoot, then disable p=reject, 
troubleshoot the failures, and forward them on to their intended 
recipients, so no email ends up getting lost. But if it's up to the 
discretion of the MTA whether to generate a bounce report, then even 
if we only enable p=reject for a short period of time, we could end up 
causing legitimate emails to be lost, and we'd really rather not have 
that happen.


Thanks,

Jonathan Kamens




___
dmarc-discuss mailing list
dmarc-discuss@dmarc.org
http://www.dmarc.org/mailman/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] OOF failed DMARC verification by linkedin

[Roland Turner via dmarc-discuss]

Despite the error message showing up in a DMARC context, this sounds 
more like a failure in how your OOO responses are created.


For example, if LinkedIn sends you:

   MAIL
   
FROM:<44a037374908b416988bae2914f01ccc32dadbf94fb7b0cceb2b8aa7aa8b5...@bounce.linkedin.com>
   RCPT TO:
   ...
   From: LinkedIn Updates 
   To: User 


Then a human-generated response whould look like:

   MAIL FROM:
   RCPT TO:
   ...
   From: User 
   To: LinkedIn Updates 

(this will bounce of course); while a machine-generated response should 
look something like:


   MAIL FROM:<>
   RCPT
   
TO:<44a037374908b416988bae2914f01ccc32dadbf94fb7b0cceb2b8aa7aa8b5...@bounce.linkedin.com>
   ...
   From: User 
   To: LinkedIn Updates 


The empty MAIL FROM is designed specifically to stop machine-generated 
responses (like OOO responses) from causing the creation of more 
machine-generated responses. By copying the MAIL FROM address of the 
incoming message to the RCPT TO of the machine-generated response, 
LinkedIn is helped to use the VERP information 
(44a037374908b416988bae2914f01ccc32dadbf94fb7b0cceb2b8aa7aa8b585f in 
this case) to automatically work out which address is failing.


However, if you have a buggy OOO generator, you might be doing something 
like:


   MAIL FROM:<>
   RCPT TO:
   ...
   From: User 
   To: LinkedIn Updates 


which is correctly setting MAIL FROM to be empty - as required for 
machine-generated responses - but incorrectly copying RCPT TO from the 
message header rather (From:) than from the envelope (MAIL FROM:). 
Because LinkedIn uses VERP (thereby causing all bounces to go to 
bounce.linkedin.com), they would respond with an error about a blank 
MAIL FROM (because their main domain never receives bounces), which is 
what you're seeing.


- Roland



On 05/06/17 11:09, Yeo via dmarc-discuss wrote:


Hi all,

We just recently enabled DMARC for our outgoing mails. We noticed our 
out of office (OOF) messages to internet so far ok e.g gmail.com.


But when OOF messages send to linkedin.com we will get DMARC 
verification failed due to Original-Mail-From is blank.


How to overcome such issue as a sender?

Thanks.

Regards,

*Yeo*



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

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



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

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

Re: [dmarc-discuss] Fwd: Hotmail forwarding

[Roland Turner via dmarc-discuss]

I meant to add: it would be sensible to create a hotmail.com account 
yourself and test the simple case of a freshly-created account. This 
won't tell you everything, but it will tell you whether your setup is 
broken even for simple Microsoft cases.


- Roland



On 31/03/17 16:13, Roland Turner wrote:

Ah yes, idiot taste tasting :-)

I can't pick it on this one; it's spent an astonishing number of hops 
inside Microsoft. I'd hazard a guess that there's some user-specified 
forwarding going on, perhaps between a free account and a corporate 
account, or vice versa, which is leading to breakage. This would 
explain reassessing SPF when the message was forwarded from one 
Microsoft address (40.92.65.94) to another. It doesn't otherwise make 
much sense, but configurations take time to optimise in large 
environments of course.


I do note two gems:

  * Test mode DKIM: "dkim=fail (*testing mode*; identity alignment
result is pass and alignment mode is relaxed)
header.d=groups.ilovefreegle.org" and in the DNS
"x._domainkey.groups.ilovefreegle.org. 3599 IN TXT "v=DKIM1;
*t=y*; k=rsa; p=MHwwDQYJKoZ...". I'd be getting rid of t=y.
  * Short DKIM key: "dkim=ignore (*ignored public key size*)
header.d=groups.ilovefreegle.org;hotmail.com". You're using a 1024
bit key, Microsoft is using a 2048 bit key. I've stopped paying
close attention, but perhaps they've decided that 1024 bits
doesn't cut it. I'd consider switching to 2048 bit.

- Roland



On 31/03/17 15:35, Edward Hibbert via dmarc-discuss wrote:
On Mon, Mar 27, 2017 at 7:20 PM, Steve Atkins 
> wrote:



> On Mar 27, 2017, at 11:19 AM, Edward Hibbert
> wrote:
>
>
>
> -- Original Message --
> From: "Steve Atkins via dmarc-discuss" >
> To: "dmarc-discuss" >
> Sent: 27/03/2017 18:53:59
> Subject: Re: [dmarc-discuss] Hotmail forwarding
>
>>
>> You're DKIM signing a message with a selector/d= pair for
which there's no public key published in DNS. That seems like a
mistake, and means your mail isn't DKIM signed.
>>
>> If SPF fails due to forwarding (which it usually will, that's
what SPF does) and your mail isn't DKIM signed, that'll trigger
DMARC action.
> I think you're right, and I'm an idiot who can't use the
interface to my DNS.  I'll put the DNS record in correctly.

:)

There's an online checker at
http://tools.wordtothewise.com/authentication
 if you want to
check that it's published correctly once you're done.


Well, I corrected it yesterday, and checked it using 
http://dkimvalidator.com/  , but I'm still 
getting NDRs (example below).  I would be grateful for any indication 
of what flavour of idiot I am currently being.


Edward



Delivered-To: edw...@ehibbert.org.uk 
Received: by 10.129.159.149 with SMTP id w143csp1699298ywg; Tue, 28 
Mar 2017

 05:16:54 -0700 (PDT)
X-Received: by 10.129.154.201 with SMTP id
 r192mr22023444ywg.324.1490703414422; Tue, 28 Mar 2017 05:16:54 -0700 
(PDT)
Return-Path: 
>
Received: from mail-yw0-x247.google.com 
 (mail-yw0-x247.google.com 
.
 [2607:f8b0:4002:c05::247]) by mx.google.com  
with ESMTPS id
 d72si1304661ywh.114.2017.03.28.05.16.53 for >
 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); 
Tue, 28 Mar

 2017 05:16:53 -0700 (PDT)
Received-SPF: pass (google.com : domain of
dist-list-geeks+bncbd4pj45lrqhrbnni5hdakgqebbss...@ilovefreegle.org 


 designates 2607:f8b0:4002:c05::247 as permitted sender)
 client-ip=2607:f8b0:4002:c05::247;
Authentication-Results: mx.google.com ; dkim=pass
 header.i=@ilovefreegle-org.20150623.gappssmtp.com 
; spf=pass 
(google.com :
 domain of 
dist-list-geeks+bncbd4pj45lrqhrbnni5hdakgqebbss...@ilovefreegle.org 


 designates 2607:f8b0:4002:c05::247 as permitted sender)
 smtp.mailfrom=dist-list-geeks+bncbd4pj45lrqhrbnni5hdakgqebbss...@ilovefreegle.org 

Re: [dmarc-discuss] Can dmarc-discuss-owner please step forward?

[Roland Turner via dmarc-discuss]

I'd add the the unsubscribe process has the same problem with clicking 
the confirmation link, and that using the reply-to-message approach 
works here too.


- Roland



On 02/08/2017 04:18 PM, Roland Turner via dmarc-discuss wrote:


That's the problem I'm having. It turns out that you can successfully 
use the email approach suggested further down the confirmation email 
instead of clicking the link.



- Roland



*From:* dmarc-discuss <dmarc-discuss-boun...@dmarc.org> on behalf of 
Jim Popovitch via dmarc-discuss <dmarc-discuss@dmarc.org>

*Sent:* Saturday, 4 February 2017 18:49
*To:* DMARC Discussion List
*Subject:* Re: [dmarc-discuss] Can dmarc-discuss-owner please step 
forward?

On Fri, Feb 3, 2017 at 7:45 PM, Roland Turner via dmarc-discuss
<dmarc-discuss@dmarc.org> wrote:
>
> I've been having a subscription management problem for a couple of 
weeks, can't solve it myself, and the dmarc-discuss-owner alias 
doesn't appear to be working/responding.

>

It's also broken when confirming a subscription via the web interface
using the link provided during the signup process.

-Jim P.
___
dmarc-discuss mailing list
dmarc-discuss@dmarc.org
http://www.dmarc.org/mailman/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] Why do I receive RUAs for emails that align?

[Roland Turner via dmarc-discuss]

Jim Popovitch wrote:

 You should definitely disregard reports that aren't useful to you.
>>>
>>> I'd actually prefer to work with the sender in order to fully
>>> understand the differences between what they see and what larger
>>> receivers see.
>>
>> Given that feedback is provided on an as-is basis, and particularly given
>> your assertion immediately below, your preferences are presumably not
>> relevant to this question.
>
> Thank you Mr. Manners.

I don't follow. Are you conceding that receivers sending reports may not find 
your preferences terribly important?

> That's just your opinion, man.   For the good of the industry they do
> have an obligation to get it right.

The self-entitled act - Dudeist or otherwise - tends to be an ineffective 
motivator for others, even when it doesn't engender outright resistance.

>>> Let me reiterate something I've said a few times now.   I only need 1
>>> accurate report, that attests to alignment, to know that my work is
>>> complete.   The rest are chaff, and I've got no interest in reading
>>> reports on chaff.
>>
>> This claim is difficult to reconcile with the fact that you continue to look
>> at smaller receivers' feedback and then complain about their failure to
>> provide with accurate data. If this claim were correct, then
>> your observed behaviour would be that you'd check against Yahoo! and/or
>> Gmail and then not even look at other receivers' reports. This quite clearly
>> does not describe the situation correctly and therefore invalidates your
>> claim.
>
> You are just reading and seeing what you want to see.   It's pretty
> clear that I don't need to look at all reports, all the time; but that
> I do, on occasion, look at all reports to see how things are going.

I'm merely reading what you wrote (and indeed, quoting it). Expanding my 
earlier comment below, you:
- switch position to the narrow interest of only caring about enough feedback 
to test your code when your obligation argument is refuted,
- switch back to your self-entitled "obligation" position when your narrow 
interest claim is refuted by citing your own behaviour,
- and then start the cycle again.

It's clear that you do care about the broader issues despite your repeated 
claims to the contrary, the difficulty is that you respond to this by trying to 
make it other people's obligation to serve you. There is a lengthy track record 
in addressing email abuse of this approach not being effective. Paraphrasing 
(and inverting) John Levine's oft-repeated observation about funding the costs 
of solving impersonation/domain-abuse problems: receivers have a budget of $0 
to solve MLMs' problems.

> In it's infancy DMARC was designed for transactional email, not human
> generated content.

 This is not correct. Right from the first high-volume domain with a
 p=reject
 policy (paypal.com) there was a mix of transactional and human-generated
 email with the same domain-name.
>>>
>>> I'm not going to dig up the history (esp at this hour of the AM before
>>> the coffee is done brewing) but it's there in one of the early specs.
>>> I've highlighted it before on this list.
>>
>> It is you who raised the history in support of your argument. If you're
>> conceding that DMARC was originally designed/intended/implemented for use
>> with individual email then this is moot. If not, then I'd happy to address
>> any actual quote from relevant source material that appears to support your
>> argument.
>
> It's the first hit when you Google for "dmarc transactional"... should
> I put that in a lmgtfy format for you?  :-)

Noting Google's tendency to personalise results, posting the link to the page 
and quoting the text would have been sensible. I'm assuming that you mean, from 
https://dmarc.org/wiki/FAQ :

dmarc.org> DMARC technology is best-suited for transactional emails and 
semi-transactional emails. Users that suddenly cannot reach the other members 
of a mailing list ...

This is an obviously correct statement about the current situation; were it not 
so, ARC would not exist. Your incorrect statement (still quoted above) was 
about what DMARC was designed to do, not about its present status.

>> You appear to have multiple conflicting intentions (receivers are/are-not
>> obliged to you, you want to examine only-one/all receivers' reports, etc.).
>
> The world is multi-faceted, I apologize if the number of angles in
> this thread has exceeded your capabilities.

Facets and angles are fine, it's your repeated self-contradiction that I was 
addressing.

> To reiterate, I want to only look at necessary reports, but reserve
> the right to, on occasion, dive deeper to try and route out and
> further understand misc issues (you call them warts).

As with your preferences, your rights do not appear to be at issue here. That 
you actually "dive deeper" is indeed part of my argument above.

>> Paying someone to report on suspect data is the opposite of what I proposed
>> 

Re: [dmarc-discuss] Can dmarc-discuss-owner please step forward?

[Roland Turner via dmarc-discuss]

That's the problem I'm having. It turns out that you can successfully use the 
email approach suggested further down the confirmation email instead of 
clicking the link.


- Roland


From: dmarc-discuss <dmarc-discuss-boun...@dmarc.org> on behalf of Jim 
Popovitch via dmarc-discuss <dmarc-discuss@dmarc.org>
Sent: Saturday, 4 February 2017 18:49
To: DMARC Discussion List
Subject: Re: [dmarc-discuss] Can dmarc-discuss-owner please step forward?

On Fri, Feb 3, 2017 at 7:45 PM, Roland Turner via dmarc-discuss
<dmarc-discuss@dmarc.org> wrote:
>
> I've been having a subscription management problem for a couple of weeks, 
> can't solve it myself, and the dmarc-discuss-owner alias doesn't appear to be 
> working/responding.
>

It's also broken when confirming a subscription via the web interface
using the link provided during the signup process.

-Jim P.
___
dmarc-discuss mailing list
dmarc-discuss@dmarc.org
http://www.dmarc.org/mailman/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] Can dmarc-discuss-owner please step forward?

[Roland Turner via dmarc-discuss]

I've been having a subscription management problem for a couple of weeks, can't 
solve it myself, and the dmarc-discuss-owner alias doesn't appear to be 
working/responding.


- Roland


[https://www.trustsphere.com/images/signatures/trustsphere.gif] Roland 
Turner
Chief Privacy Officer
Mobile: +65 9670 0022
13-03 Royal Group Building, 3 Phillip Street, Singapore 048693


[facebook]  [twitter] 
 [linkedin] 
   [youtube] 

www.trustsphere.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] Why do I receive RUAs for emails that align?

[Roland Turner via dmarc-discuss]

Jim Popovitch wrote:


>> You should definitely disregard reports that aren't useful to you.
>
> I'd actually prefer to work with the sender in order to fully
> understand the differences between what they see and what larger
> receivers see.

Given that feedback is provided on an as-is basis, and particularly given your 
assertion immediately below, your preferences are presumably not relevant to 
this question.

>> This and some earlier remarks[1] suggest that you're treating DMARC as a
>> product or service that you're being invited to purchase and whose vendor is
>> therefore motivated to present a product or service that is to your liking -
>
> Absolutely not.   There is nothing I've said to remotely indicate
> that, even that footnoted comment doesn't suggest I feel others have
> an obligation to meet my demands.   They do, however, have an
> obligation to send accurate data, and if they don't that is
> disingenuous.

Setting aside the mismatch between my observation and your response, you 
contradict yourself. Receivers who are providing you with feedback, on a gratis 
and as-is basis, obviously don't have the obligations that you are asserting.

> Let me reiterate something I've said a few times now.   I only need 1
> accurate report, that attests to alignment, to know that my work is
> complete.   The rest are chaff, and I've got no interest in reading
> reports on chaff.

This claim is difficult to reconcile with the fact that you continue to look at 
smaller receivers' feedback and then complain about their failure to provide 
with accurate data. If this claim were correct, then
your observed behaviour would be that you'd check against Yahoo! and/or Gmail 
and then not even look at other receivers' reports. This quite clearly does not 
describe the situation correctly and therefore invalidates your claim.

>>> In it's infancy DMARC was designed for transactional email, not human
>>> generated content.
>>
>> This is not correct. Right from the first high-volume domain with a p=reject
>> policy (paypal.com) there was a mix of transactional and human-generated
>> email with the same domain-name.
>
> I'm not going to dig up the history (esp at this hour of the AM before
> the coffee is done brewing) but it's there in one of the early specs.
> I've highlighted it before on this list.

It is you who raised the history in support of your argument. If you're 
conceding that DMARC was originally designed/intended/implemented for use with 
individual email then this is moot. If not, then I'd happy to address any 
actual quote from relevant source material that appears to support your 
argument.

>> continue assessing DMARC feedback yourself, and accept that it contains
>> warts and will never be perfect;
>> find a vendor who will provide digested feedback which makes all of the
>> unpleasantness go away before you see it (this is costly, and the likelihood
>> of an exact match between your desires and the services on offer is low,
>> however...); or
>> disregard DMARC feedback entirely.
>
> I think I've already made my intention well known, and I would never
> pay someone to report on suspect data.

You appear to have multiple conflicting intentions (receivers are/are-not 
obliged to you, you want to examine only-one/all receivers' reports, etc.).

Paying someone to report on suspect data is the opposite of what I proposed and 
you quoted.

>> Agitating to have low level feedback mechanisms not have low-level warts is
>> unlikely to succeed, particularly when that feedback is provided gratis.
>
> Thank goodness other solid ideas didn't struggle with those fiefdom
> issues.   Imagine if FBLs and ARF had been subjected to this
> pay-to-play model you're advocating.

I don't advocate a pay-to-play model, I merely point it out as the appropriate 
option for someone who wants real-world warts removed for him, rather than deal 
with them himself. The same is true for FBLs, SMTP, hosting, datacentres, 
technology generally. Your options are always some combination of build (and 
deal with the warts), buy (and pay someone else to deal with most/all of the 
warts), or desist.

Like processing DMARC feedback, processing FBLs requires dealing with 
real-world warts, particularly with non-uniform redaction policies. DMARC 
feedback happens to expose more complicated differences in how different 
receivers process email (like skipping DKIM verification when SPF has already 
passed) and so is perhaps more work to consume usefully, but the broad 
situation is the same: here is what our real-world system is capable of 
reporting, you are welcome to receive it if it is useful to you.

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

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

Re: [dmarc-discuss] A bit quiet?

[Roland Turner via dmarc-discuss]

John Payne wrote:


> Spoke too soon. I'm getting reports of IETF list mail from @akamai.com ending 
> up in Gmail spam folders :(
>
>> On Jan 31, 2017, at 9:07 AM, Payne, John via dmarc-discuss 
>>  wrote:
>>
>> And it did the trick.  Down to a manageable number of failures now, thanks 
>> for the hint Brandon :)

Presumably this just indicates that the rewrite rule that Brandon described for 
Google Groups is not in use by IETF's mailing lists?

Tradeoffs in every direction...

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

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

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

[Roland Turner via dmarc-discuss]

Jim Popovitch wrote:

> The difficulty I have is exactly as you described.   I received a
> DMARC report that says there is a DKIM failure, but what is not clear
> is whether or not the email was "quite possibly not tested or
> recorded".   That DMARC report is pointless without knowing more.

You should definitely disregard reports that aren't useful to you.

This and some earlier remarks[1] suggest that you're treating DMARC as a 
product or service that you're being invited to purchase and whose vendor is 
therefore motivated to present a product or service that is to your liking - 
and perhaps to improve it to that end - in order to encourage you to purchase. 
That's not what's going on. Partial visibility into receivers' systems is being 
provided, gratis, on an as-is basis (warts and all), in order to allow 
interested domain registrants/owners to take action to tighten their own 
practices and to detect and act against fraudulent uses of their domains. 
Experience to date suggests that what is being provided is appropriate and 
useful to that end. There remains scope for improvement of course, and the fact 
that some receivers' systems don't work in a way that even gathers the 
information that you'd like to receive - let alone report it - is an 
unfortunate fact of real world email systems.

If you're unwilling or unable to process raw feedback, then you should perhaps 
seek out a service provider whose expertise includes dealing with the rough 
edges. There are several; naturally, most cost [quite a bit of] money.

> In it's infancy DMARC was designed for transactional email, not human
> generated content.

This is not correct. Right from the first high-volume domain with a p=reject 
policy (paypal.com) there was a mix of transactional and human-generated email 
with the same domain-name.

>  In those days pundits decreed that DMARC wasn't
> for MLMs and that mailinglists would be whitelisted and treated with
> special care.  As it turns out, the truth is somewhat different.

This is hardly surprising. Pundits should be considered entertainers, not 
oracles.

> Of course, my interest has now turned to
> trying to understand why XYZ determines there is a failure (was it a
> DNS problem?, was there a middle man?, etc.).  The end goal being
> perfect delivery, sans any problems or implication of there being a
> problem needing investigation or effort on my part.

This is fair enough, but as above, you'll do better if you understand the 
limitations of the tools that you're working with. Choices include:

  *   continue assessing DMARC feedback yourself, and accept that it contains 
warts and will never be perfect;
  *   find a vendor who will provide digested feedback which makes all of the 
unpleasantness go away before you see it (this is costly, and the likelihood of 
an exact match between your desires and the services on offer is low, 
however...); or
  *   disregard DMARC feedback entirely.

Agitating to have low level feedback mechanisms not have low-level warts is 
unlikely to succeed, particularly when that feedback is provided gratis.

- Roland

1: 'It is disingenuous, imho, for a receiver to submit a DMARC report to a 
sender if the subtle failures are receiver side or if those reports don't 
contain enough information for the receiver to understand the reason(s) for the 
subtle failure ("give me the RUF or STFU").  :-)'
___
dmarc-discuss mailing list
dmarc-discuss@dmarc.org
http://www.dmarc.org/mailman/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] opendkim-atpszone reproducibility and examples

[Roland Turner via dmarc-discuss]

I'd suggest that reliance upon ADSP is unwise as - having being reclassified as 
historic - it could stop working at any time without warning. A better option 
might be to sign your reports with the DKIM signature of the reporting domain 
(i.e. sign with example.eu instead of example.com in your obscured example).


- Roland


From: dmarc-discuss  on behalf of SheridanJ 
West via dmarc-discuss 
Sent: Wednesday, 1 February 2017 00:53
Cc: dmarc-discuss@dmarc.org
Subject: Re: [dmarc-discuss] opendkim-atpszone reproducibility and examples


i appear to need atps records for google this is with atps dns text records and 
probably others

opendmarc-reports: sent report for gmail.com to 
mailauth-repo...@google.com (2.0.0 Ok: 
queued as x1)
Gmail
gmail.com
Gmail is email that's intuitive, efficient, and useful. 15 GB of storage, less 
spam, and mobile access.



postfix/smtp[28130]: x2: 
to=>,
relay=aspmx.l.google.com[66.102.1.26]:25, delay=0.87,
delays=0.13/0.01/0.25/0.48, dsn=2.0.0,
status=sent (250 2.0.0 OK xx xx - gsmtp)

without atps [results i got from last week]

postfix/smtp[5820]:
 x0: to=>,
relay=aspmx.l.google.com[74.125.71.26]:25, delay=1.1,
 delays=0.13/0.01/0.49/0.43, dsn=5.7.1, status=bounced
(host aspmx.l.google.com[74.125.71.26] said: 
550-5.7.1
Unauthenticated email from example.eu  is not accepted
due to 550-5.7.1 domain's DMARC policy.
Please contact the administrator of 550-5.7.1 example.eu
domain if this was a legitimate mail.

I used (appears to work) dns records

 _adsp._domainkey.example.eu.  "dkim=all 
atps=y; asl=example.com;"
http://example.com>>._atps.example.eu. 
"v=atps01; d=example.com;"

not work (or tried yet) the content made by openmarc-atpszone

v=ATPS1; d=example.net

The windows version appears to be the winner for syntax of atps.

although i can get sha1 domain name hashes from both with.

opendkim-atpszone -h sha1 -u example.com -A 
example.net


So most of opendkim-atpszone is best ignored it appears


On Tue, Jan 31, 2017 at 2:17 PM, Juri Haberland via dmarc-discuss 
> wrote:
SheridanJ West via dmarc-discuss wrote:
> I encountered a opendmarc bug that required adsp records as well to send
> dmarc reports and i had a fun time trying to reproduce the output for i do
> not know how long the url i mention will last.

> Is nearly the same but I am confused - is the web parser right and the
> opendkim-atpszone command wrong? with v=ATPS1

> I ask as this affects only dmarc reports (no i do not run 
> example.com) our
> normal email is sent ok

Even though this is not an OpenDMARC specific mailing list but a generic DMARC
discussion list, can you be a bit more specific in which way OpenDMARC reports
are affected by the differing output of the webtool vs. opendkim-atpszone?

  Juri

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

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

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

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

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

[Roland Turner via dmarc-discuss]

Jim,


Bear in mind that all reporting is at the good graces of receivers; the options 
to fine-tune what is sent may, or may not, actually be implemented by any given 
receiver. (This isn't an interoperability or conformance comment so much as a 
real-world systems one. Postel's Law definitely applies.) Anything that you can 
reasonably do by yourself with the data that you are given is something that 
you should be willing to do, at least for some receivers some of the time. 
Trying to use the DMARC options as configuration tools to fine-tune what data 
you work with isn't likely to work very well, that's something that you should 
be doing with the tools that you use to process the data that you receive.


Disregarding (and even not requesting) aggregate reports is your prerogative of 
course, but note that even amongst receivers who will send aggregate reports to 
strangers (organisations with whom they don't not have formal NDAs), the vast 
majority will not send failure reports. Most of the useful information that 
DMARC will give you is to be found in the aggregate reports.


- Roland


From: dmarc-discuss  on behalf of Jim 
Popovitch via dmarc-discuss 
Sent: Friday, 27 January 2017 07:43
To: John Levine
Cc: dmarc-discuss@dmarc.org
Subject: Re: [dmarc-discuss] Why do I receive RUAs for emails that align?

On Thu, Jan 26, 2017 at 5:50 PM, John Levine  wrote:
> In article 
>  you 
> write:
>>Hello,
>>
>>I'm trying to limit RUA/RUFs to legitimate emails that need eyeballs.
>>
>>To that end, I'm scratching my head as to why I get RUAs that clearly align.
>
> That's how it works.  See section 7.2 of RFC 7489.  Aggregate reports
> tell you about all the mail a system got that has your domain on the
> From: line.
>
> Everyone I know automatically parses the aggregate reports and puts
> the info in a database so they can query it about whatever is of
> interest.
>
> Here's some scripts I give away that do the parse and put in a database part.
>
> http://www.taugh.com/rddmarc/
>
> R's,
> John

Thanks John,

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

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

[Roland Turner via dmarc-discuss]

John Payne wrote:

> That's awesome.  Do we have enough implementers on this list to gain any 
> confidence on whether or not
> p=quarantine and pct=0 would enforce quarantine or not?

It is a reasonably safe bet that pct=0 will prevent quarantining. (Any receiver 
observed doing otherwise will no doubt be promptly encouraged to stop doing 
so.) Whether other forwarders will rewrite in this case is an open question.

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

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

Re: [dmarc-discuss] RUF reports

[Roland Turner via dmarc-discuss]

A local_policy override is a discretionary choice by the receiver; it's not 
clear what choice is being made or why.


Failure reports are sent at the discretion of the receiver, and then only when 
they determine a failure, which in this case has not occurred for 
receiver-local reasons.


- Roland


From: dmarc-discuss  on behalf of Jim 
Popovitch via dmarc-discuss 
Sent: Friday, 6 January 2017 09:32
To: dmarc-discuss@dmarc.org
Subject: [dmarc-discuss] RUF reports

Hello,

I've been trying, albeit slowly, to determine why I haven't seen any
RUF reports since Sept 2016.

Shouldn't this RUA report also produce a corresponding RUF?

http://domainmail.org/dmarc-reports/126.com%21inug.org%211483574400%211483660799.xml

-Jim P.
___
dmarc-discuss mailing list
dmarc-discuss@dmarc.org
http://www.dmarc.org/mailman/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 report from Google shows unexpected result

[Roland Turner via dmarc-discuss]

Jim Garrison wrote (after John Levine wrote):


>> When you looked at your outgoing mail logs for mail you sent yesterday
>> to MTAs in the IP range 209.17.112.0/21, which is one of web.com's
>> hosting farms, what did you find?
>
> My mail logs show no outgoing connections to any IP address in
> 209.17.0.0/16.  My server is very low volume (handles my personal
> mail only).  Here's the list of outgoing connections for the last
> several days:

John was perhaps simplifying a little too far.

The report from Gmail is telling you that a message validly signed with your 
domain - and that domain or an aligned one in the From: header - arrived from 
the IP address in question. This seems like a pretty typical forwarding case, 
albeit with two or more steps instead of one. What is it that makes you think 
that the message has a "spoofed From:
domain matching mine"?

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

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

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

[Roland Turner via dmarc-discuss]

Steven M Jones wrote:

> Some of your subdomains may send infrequently, and you may not know what
> all of them are until end of month/quarter. Depending on what's
> happening with the parent domain, this odd-looking policy might be your
> better option for the interim.

Certainly, but that's also true for independent systems that are sending only 
infrequently from the parent domain too. I can see the general point (that a 
mechanism with a narrow, defined scope might be a useful step in a staged 
implementation), but am not yet convinced that there are real world 
technical/security situations where this makes sense. In general, you're either:

- implementing in haste because you've detected serious abuse, in which case 
sp=none simply hands your adversary an enormous entry; or

- implementing at a more deliberate pace, in which case infrequently-sending 
sources can be mapped properly.

> And second, sometimes you can only do what you can convince the customer
> to accept. I've had the "business decision maker" refuse to block ~1
> million fraudulent messages per day because up to 500 legit messages
> (out of more than 50,000) per day would also be blocked due to
> forwarding. And that was their decision to make, since it was a business
> decision.
>
> So I'm not saying it's a great choice, but in some cases it may be what
> gets you the next step forward.

Sure, poorly-informed "business decisions" (or well-informed business decisions 
using different risk perspectives) aren't going away any time soon, we all need 
to make a living. I was looking specifically for technical/security situations 
where sp=none made sense, rather than seeking to argue for the removal of the 
option.

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

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

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

[Roland Turner via dmarc-discuss]

Povl Hessellund wrote:

> We are not alone here. We have all sorts of systems like newsletters (they do 
> DKIM etc),
> HR system, time registration system, other misc systems. Maybe it is 10 
> subdomains only,
> and maybe we should just create DMARC record for all of them with p=none - 
> and  not
> depend on sp=none.

That is my guess, yes. A basic assumption that DMARC makes (indeed, the reason 
the feedback mechanism exists) is that p=reject may cause legitimate email loss 
so anyone using it will be closely monitoring their feedback and has spent the 
time to sort out their existing email streams before turning on p=reject. That 
exercise would necessarily include identifying legitimate streams that can't 
[yet] be caused to authenticate, so they would be readily excluded by creating 
subdomain-specific p=none records, which could be withdrawn over time as the 
issues are resolved.

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

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

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

[Roland Turner via dmarc-discuss]

Rolf E. Sonneveld wrote:

> On 12-12-16 07:47, Roland Turner via dmarc-discuss wrote:
>> it's not at all clear why "p=reject sp=none" would ever be a good idea.
>
> actually I have two customers using mail for both their office automation
> and for business processes. Both of them use their domain for office
> automation mail and a subdomain thereof for business process mail. A
> DMARC policy for their office  environment may not have impact on their
> business process mail traffic.

OK, but presumably the business process system isn't generating new subdomains 
on an hourly/daily basis (or indeed, ever). Assuming that simply fixing the BPS 
outbound email stream to have valid DKIM signatures is not an option (e.g. 
delivery via corporate gateway), then presumably this is better dealt with as:

_dmarc.example.com TXT "p=reject"
_dmarc.bps.example.com TXT "p=none"

than with a blanket sp=none in the parent domain?

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

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

Re: [dmarc-discuss] FBL via DMARC?

[Roland Turner via dmarc-discuss]

I should have pointed out first that this question is unrelated to DMARC. At 
best, we're discussing a comparable "put a record in the DNS" configuration 
mechanism for requesting abuse reports. Note in particular that "put abuse 
contacts into abuse.net" already exists, and isn't being overwhelmed.


The principal means of addressing the privacy issues is the FBL signup process 
in which (a) the requester enters into an NDA and (b) the FBL service provider 
(typically a contractor to the receiver, rather than the receiver themselves) 
vets the applicant organisation and the individual's likely competence to 
execute the NDA. This can't be entirely automated, meaning that the benefits of 
universal access that DMARC provides aren't achievable.


- Roland


From: Gil Bahat <g...@magisto.com>
Sent: Tuesday, 29 November 2016 13:33
To: Roland Turner
Cc: DMARC Discussion List
Subject: Re: [dmarc-discuss] FBL via DMARC?

Hi,

these are all solvable while still remaining within the DMARC domain: e.g. 
enabling detailed reports only after a specific signup procedure.

most large receivers do have a feedback loop in place, even though not all of 
them standard. standardization would be really helpful as well as allow better 
and easier FBL management.
I'd really like to see this in the DMARC standard, even if not everyone will 
apply it (e.g. DMARC failure reports). The privacy considerations are also 
apparently a non-issue as the overwhelming majority of mail providers (infact 
everyone but google) provide email-level FBL reports - Yahoo, Hotmail, AOL, 
mail.ru<http://mail.ru>, yandex, italia online, ...
[http://upload.wikimedia.org/wikipedia/commons/thumb/b/bf/Mail.Ru_logo.svg/240px-Mail.Ru_logo.svg.png]<http://mail.ru/>

Mail.Ru: ?, ? ? ?, ???, <http://mail.ru/>
mail.ru
? Mail.Ru - ?? ?? ?, ??? ? ??? ?, 
?? ...


Gil

On Tue, Nov 29, 2016 at 6:55 AM, Roland Turner via dmarc-discuss 
<dmarc-discuss@dmarc.org<mailto:dmarc-discuss@dmarc.org>> wrote:

I'd hazard a guess that confidentiality constraints get in the way here, for 
the same reason that most receivers won't provide DMARC failure reports, only 
aggregate reports.


Note that the feedback mechanism for receivers who wish to volunteer reports 
already exists - and is the origin of DMARC's ARF - that being to send to abuse 
contacts for the domain or the originating IP address. Those same 
confidentiality constraints mean that few receivers do so.


A further concern for spam filters in particular is that a receiver has to be 
confident that the domain-owner is a legitimate sender; if not, the abuse 
reports are a tuning tool for a spammer. No receiver wants to help this happen.


- Roland


From: dmarc-discuss 
<dmarc-discuss-boun...@dmarc.org<mailto:dmarc-discuss-boun...@dmarc.org>> on 
behalf of Jonathan Knopp via dmarc-discuss 
<dmarc-discuss@dmarc.org<mailto:dmarc-discuss@dmarc.org>>
Sent: Tuesday, 29 November 2016 12:22
To: dmarc-discuss@dmarc.org<mailto:dmarc-discuss@dmarc.org>
Subject: [dmarc-discuss] FBL via DMARC?

Has there been any discussion about using DMARC to configure spam complaint 
feedback loops? Currently it is only feasible to register for the big ESPs and 
can be tough to keep them up to date. DMARC could make this automatic and 
universal. It would be well within DMARC's mandate of domain reputation 
protection since it would let you know quickly when someone has infiltrated 
your systems and is sending spam via your legitimate email path.
___
dmarc-discuss mailing list
dmarc-discuss@dmarc.org<mailto:dmarc-discuss@dmarc.org>
http://www.dmarc.org/mailman/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<mailto:dmarc-discuss@dmarc.org>
http://www.dmarc.org/mailman/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] FBL via DMARC?

[Roland Turner via dmarc-discuss]

I'd hazard a guess that confidentiality constraints get in the way here, for 
the same reason that most receivers won't provide DMARC failure reports, only 
aggregate reports.


Note that the feedback mechanism for receivers who wish to volunteer reports 
already exists - and is the origin of DMARC's ARF - that being to send to abuse 
contacts for the domain or the originating IP address. Those same 
confidentiality constraints mean that few receivers do so.


A further concern for spam filters in particular is that a receiver has to be 
confident that the domain-owner is a legitimate sender; if not, the abuse 
reports are a tuning tool for a spammer. No receiver wants to help this happen.


- Roland


From: dmarc-discuss  on behalf of Jonathan 
Knopp via dmarc-discuss 
Sent: Tuesday, 29 November 2016 12:22
To: dmarc-discuss@dmarc.org
Subject: [dmarc-discuss] FBL via DMARC?

Has there been any discussion about using DMARC to configure spam complaint 
feedback loops? Currently it is only feasible to register for the big ESPs and 
can be tough to keep them up to date. DMARC could make this automatic and 
universal. It would be well within DMARC's mandate of domain reputation 
protection since it would let you know quickly when someone has infiltrated 
your systems and is sending spam via your legitimate email path.
___
dmarc-discuss mailing list
dmarc-discuss@dmarc.org
http://www.dmarc.org/mailman/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

[Roland Turner via dmarc-discuss]

Petr,

Do you also kick small dogs? I'd suggest that a 2-week turnaround on a bug 
that's non-critical for Fortinet's customers is pretty impressive.

On the meaning of "by design", there are of course multiple designs 
(intentions) present. Surely you're familiar with the tree-swing project 
management cartoon? You know this happens all the time in real engineering 
organisations, right?

http://www.tamingdata.com/wp-content/uploads/2010/07/tree-swing-project-management-large.png

- Roland



From: dmarc-discuss  on behalf of Petr Novák 
via dmarc-discuss 
Sent: Friday, 25 November 2016 17:57
To: dmarc-discuss@dmarc.org
Subject: Re: [dmarc-discuss] Getting to reject, was :Re: FortiNet’s FortiMail 
DMARC implementation
    
Well if it wasn't by design then how do you explain this reply from your
support team. quote:

"I've got feedback from engineering on this.
The current behavior is by design, the action for DMARC check failure is 
driven by the action next to the DMARC check (action-dmarc) no matter 
the DMARC policy (p=) setting."

Which then continued with:

"Thank you for the feedback. I agree that it would be nice to respect 
the "none" or give more control over what action should be done in which 
case.
But as per update from engineering the current FortiMail behavior is by 
design and there is no current plan to change the behavior."


Anyway I am glad that it will be fixed.

Regards
   Petr

Dne 25.11.2016 v 10:36 Carl Windsor via dmarc-discuss napsal(a):
> 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] FortiNet’s FortiMail DMARC implementation

[Roland Turner via dmarc-discuss]

Petr Novák wrote:

> I wonder what do you guys think about it's DMARC implementation. If you 
> enable DMARC check in FortiMail it rejects(or performs other configured 
> action) any mail that fails DMARC check no matter what policy source 
> domain has configured. So it also rejects mails from domains that have 
> policy p=none. After contacting their support I was told that this 
> implementation is by desing and they dont have any plans to change it.

To clarify, does enabling the setting cause the rejection of:
- all messages that fail DMARC-like tests whether or not they have a DMARC 
record; or
- just all of those that fail checks whose 5322.From address domain has any 
DMARC record, while not performing DMARC-like tests on domains who don't.
?

That a p=none record have the same impact as no record is an important 
property, as the ability to turn on p=none without impact is an important 
enabler for domain owner/registrants to explore implementation. If FortiMail is 
implementing feature that breaks this property then it would be worth 
addressing (sadly, I have no relevant contacts).

If it's simply applying the same overzealous rules to domains with no record as 
to those with a p=none record then this is a poor choice, but not as harmful in 
that it won't affect decision-making by implementing domain owner/registrants.

> In DMARC RFC there is:
> "To enable Domain Owners to receive DMARC feedback without impacting 
> existing mail processing, discovered policies of "p=none" SHOULD NOT 
> modify existing mail disposition processing."
> 
> So I guess it doesn't break RFC if there is "SHOULD NOT" and not "MUST 
> NOT"? But I still think this implementation of DMARC is wrong. What do 
> you guys think?

The implementation is poor, but it's complying. The p= value is a request by 
the domain-owner/registrant to the receiver to do a certain thing rather than 
an instruction; the receiver retains full discretion about whether or not they 
do as asked, which is why the specification says SHOULD NOT rather than MUST 
NOT. This doesn't mean that harmful implementations wouldn't benefit from being 
improved, just that receiver discretion is a high priority.

- Roland

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

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

Re: [dmarc-discuss] A bit quiet?

[Roland Turner via dmarc-discuss]

John,


My apologies, I appear to have misinterpreted this completely, not sure what I 
was thinking:

  *   DMARC reports are sent to the address specified in the DMARC record 
associated with the 5322.From address, not the source IP addresses.
  *   Therefore, these reports are sent to you because the 5322.From header 
contains an akamai.com address.
  *   The examples that you're citing showing a 5321.MailFrom address (with SPF 
pass) and DKIM d= domain (with DKIM pass) that are aligned with each other. 
This suggests either (a) a message sent legitimately by yourselves and 
legitimately forwarded or (b) an impersonation, also legitimately forwarded. It 
is to be hoped that Google's DMARC reports preferentially report on 
DMARC-aligned DKIM passes if they're present, suggesting that the messages in 
question are passing through DKIM-breaking forwarding (case (a)) or lack DKIM 
signatures (hopefully case (b)).

I'm guessing that you'd already worked this out.


The forwarding cases are the awkward corner case for DMARC. As a domain 
owner/registrant there's probably not much that you can do about this. Someone 
like PayPal can, because of the stakes involved, stipulate that users (a) 
provide an end-address and (b) not forward it. I don't imagine that you're in a 
position to do so. ARC goes some way to helping receivers make better 
decisions, but that doesn't give you much to work with.


Is there email sent legitimately with an @akamai.com email address that isn't 
from an Akamai employee or automated system? If so, are the stakes high enough 
that you're in a position to direct employees to avoid using their work email 
addresses for mailing lists? (This won't solve the problem, but may 
significantly reduce it.) Are you able to quantify the damage being done at 
present? (If not, stop work on this now!)


- Roland


From: Payne, John <jpa...@akamai.com>
Sent: Friday, 28 October 2016 04:45
To: Roland Turner
Cc: DMARC Discussion List
Subject: Re: [dmarc-discuss] A bit quiet?


> On Oct 26, 2016, at 8:56 PM, Roland Turner via dmarc-discuss 
> <dmarc-discuss@dmarc.org> wrote:
>
> Payne, John wrote:
>
> > Yeah, but why are they showing up in _my_ DMARC reports?
> ...
> > Domain  MAIL FROM   DKIM domain SPF AuthDKIM Auth   
> > Total
> > akamai.com oppa.com.br oppa-com-br.20150623.gappssmtp.com Pass  Pass237
>
> oppa.com.br has a syntactically invalid SPF record, so it's odd that it's 
> passing at all. You didn't show which IP address the reporter saw this stream 
> coming from: were they forwarded in your environment with their DKIM 
> signatures intact?

That was just a random example.   The IPs are all Google.  These are not 
forwarded within my environment.


First couple from literally thousands of Google IPs:
IP  PTR NameSBRSCountry DMARC Fail %DMARC Fail  Total
2607:f8b0:4003:c06::247 mail-oi0-x247.google.com (IPv6) 99.96%  2,847   
2,848
2607:f8b0:4003:c06::245 mail-oi0-x245.google.com (IPv6) 99.96%  2,792   
2,793
2607:f8b0:4003:c06::246 mail-oi0-x246.google.com (IPv6) 100.00% 2,769   
2,769
2607:f8b0:4003:c06::248 mail-oi0-x248.google.com (IPv6) 99.96%  2,673   
2,674


Drilling into that first one and again, just taking the first couple because 
it’s just more of the same with many different domains:

Domain  MAIL FROM   DKIM domain SPF AuthDKIM Auth   Total
akamai.com  kohls.com   kohls-com.20150623.gappssmtp.comPass
Pass369
akamai.com  stickyads.tvstickyads.tvPassPass256
akamai.com  jforce.com.tw   jforce-com-tw.20150623.gappssmtp.comPass
Pass238
akamai.com  ziffdavis.com   ziffdavis-com.20150623.gappssmtp.comPass
Pass205



There are no RUFs generated, only RUAs.

As an example of why this is a problem for me… Yesterday out of 53,078 DMARC 
failures, 49,101 were from Google IP space.  I can’t even find the 4,000 other 
failures amongst all the Google ones to see if they’re things I need to worry 
about or not!

I’d love to understand either why I’m so special in this regard, or if I’m not 
how others are dealing with this.   We do use Google Apps (just not mail), and 
a lot of our customers are Google mail customers, so I really don’t want to ask 
Agari to filter out reports from Google - but I’m at my wits end with this.
___
dmarc-discuss mailing list
dmarc-discuss@dmarc.org
http://www.dmarc.org/mailman/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?

[Roland Turner via dmarc-discuss]

Payne, John wrote:


> Yeah, but why are they showing up in _my_ DMARC reports?
...
> Domain  MAIL FROM   DKIM domain SPF AuthDKIM Auth   Total
> akamai.com 
> oppa.com.br
>  
> oppa-com-br.20150623.gappssmtp.com
>  Pass  Pass237

oppa.com.br has a syntactically invalid SPF record, so it's odd that it's 
passing at all. You didn't show which IP address the reporter saw this stream 
coming from: were they forwarded in your environment with their DKIM signatures 
intact?

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

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

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

[Roland Turner via dmarc-discuss]

Consider https://www.ietf.org/mailman/listinfo/dmarc


- Roland




From: dmarc-discuss  on behalf of Juri 
Haberland via dmarc-discuss 
Sent: Wednesday, 12 October 2016 16:32
To: Juri Haberland
Cc: DMARC Discussion List
Subject: Re: [dmarc-discuss] Beware of the size limit in DMARC URIs

Hi,

I hoped to get a reaction here of some sort from Microsoft, Google or
Yahoo,
but my mail might got burried underneath useless rants about DMARC and
DNSSEC...

Btw: Did anyone notice that AOL sends DMARC reports with two To:
headers?


Kind regards,
   Juri


On 2016-10-04 09:21, Juri Haberland via dmarc-discuss wrote:
> Hi,
>
> while writing a patch for OpenDMARC, I stumbled accross problems with
> the
> size limit in DMARC URIs that some of the big players have.
>
> Microsoft cannot cope at all with an URI like "rep...@example.org!10m"
> -
> you won't receive a single report.
>
> Yahoo and Google do send a report and respect the size limit - as long
> as
> this URI is the only one in the rua tag.
> As soon as one adds another URI (with or without size limit) to the rua
> tag, Google and Yahoo forget to strip the size limit from the URI and
> thus
> try to send a mail to "rep...@example.org!10m"!
>
> As OpenDMARC also had problems with the size limit in older versions,
> it is
> best to avoid the use of size limits for now.
___
dmarc-discuss mailing list
dmarc-discuss@dmarc.org
http://www.dmarc.org/mailman/listinfo/dmarc-discuss

NOTE: Participating in this list means you agree to the DMARC Note Well terms 
(http://www.dmarc.org/note_well.html)
___
dmarc-discuss mailing list
dmarc-discuss@dmarc.org
http://www.dmarc.org/mailman/listinfo/dmarc-discuss

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

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

[Roland Turner via dmarc-discuss]

Benny,

I would remind you that the Note Well terms linked at the bottom of each 
message include "you agree to participate in a ... cordial manner". I would 
suggest that your conduct has slipped a little below that standard[1], and that 
it might be helpful and productive to take a different tack.

Your quoted example doesn't make sense to me, it shows a DMARC pass 
("Authentication-Results: linode.junc.eu; dmarc=pass header.from=dmarc.org"). 
What's your concern?

Receivers are free to require DNSSEC if they wish of course, however (a) making 
this mandatory in the standard would not make DMARC materially better at 
solving the problem that it's designed to solve, and (b) it would eliminate a 
very large fraction of DMARC's ability to block fraudulent email. Consequently, 
it would not be a useful change to the specification.

The same reasoning applies to requiring that all DKIM signatures pass in order 
to yield a DMARC pass.

Blacklisting a DKIM signer is an option open to receivers, yes, but receiver 
policy choices are by definition not part of the DMARC specification.

Your concerns about email client limitations are widely appreciated, but are 
out of scope for this list in that we're not in a position to fix them.

- Roland

1:
- "wake up admins" is clearly not cordial
- "i am also unimpressed of that dmarc can pass with no dnssec, badly designed" 
likewise (other members of the group do not exist to impress you)
- "bad designed on thiese maillist" could only be regarded as cordial if it 
were a step in an argument linking agreed criteria to a better implementation, 
however the situation in this case is that you happen not to agree with the 
criteria that the list administrator is pursuing, but apparently want to 
acknowledge this, meaning that your choice of terms is pejorative and not at 
cordial





From: dmarc-discuss  on behalf of Benny 
Pedersen via dmarc-discuss 
Sent: Wednesday, 5 October 2016 02:27
To: Elizabeth Zwicky
Cc: dmarc-discuss@dmarc.org
Subject: Re: [dmarc-discuss] dmarc.org breaks dkim & dmarc
    
On 2016-10-04 19:41, Elizabeth Zwicky wrote:
> The DMARC on the mailing list passes when it reaches me -- it appears
> that something in the path between you and dmarc.org is the problem
> with breaking the DKIM signature.

correct, did i get a problem on postfix maillist ?

> Since it's dmarc.org's DKIM signature, it's put on after all the
> mailing list handling, so I'm not sure why anybody thinks mailing list
> handling is involved?

dmarc.org have choiced to take over ownerships, and now its there 
problem

thats why you see dmarc still pass, but its not the originating domain 
sender

what will happend if opendmarc skips last signer if multiple signed ?, 
imho opendmarc should really be more dnssec strict, and make all dkim 
keys pass before it does dmarc pass, my msgs do pass on dmarc.org 
mailserveres, but since thay fix some unknown problem with mailman it 
will not give dkim pass on return, and hell broke out with it :(

as it is now we all loose on it :/

createing arc as another problem to solve does imho not make dkim more 
unstable or better, there was nothing to fix really, sadly
___
dmarc-discuss mailing list
dmarc-discuss@dmarc.org
http://www.dmarc.org/mailman/listinfo/dmarc-discuss

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

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

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

Re: [dmarc-discuss] dmarc fail for linkedin

[Roland Turner via dmarc-discuss]

This looks like a receiver-side bug. An SPF pass for bounces.linkedin.com 
implies a DMARC pass for linkedin.com so long as the linked.com policy 
specifies or defaults to relaxed alignment (it does).


- Roland



[https://www.trustsphere.com/images/signatures/trustsphere.gif] Roland Turner
Labs Director
Mobile: +65 9670 0022
3 Phillip Street, #13-03 Royal Group Building, Singapore 048693


[https://www.trustsphere.com/images/signatures/facebook.gif]
[https://www.trustsphere.com/images/signatures/twitter.gif] 
   
[https://www.trustsphere.com/images/signatures/linkedin.gif] 
 
[https://www.trustsphere.com/images/signatures/youtube.gif] 
  
www.trustsphere.com






From: dmarc-discuss  on behalf of DurgaPrasad 
- DatasoftComnet via dmarc-discuss 
Sent: Sunday, 2 October 2016 23:16
To: 'dmarc-discuss'
Subject: [dmarc-discuss] dmarc fail for linkedin


Hello all,

Why is dmac failing for linkedin?

following sanitised output captured from mailwatch. I thought Linkedin is 
active participant of DMARC.

Sometimes it fails for gmail also.





Received from:


108.174.6.157



Received Via:


IP Address


Hostname


Country


RBL


Spam


Virus


All


108.174.6.157


mailb-de.linkedin.com


United States

















X-Greylist: delayed 62 seconds by postgrey-1.34 at sync.recvdomain.com; Sun, 02 
Oct 2016 20:10:32 IST
DMARC-Filter: OpenDMARC Filter v1.3.1 sync.recvdomain.com 3561F1A4C04
Authentication-Results: sync.recvdomain.com; dmarc=fail header.from=linkedin.com
Authentication-Results: sync.recvdomain.com; spf=pass 
smtp.mailfrom=s-2gvpcup5oqbkzh2ybkjw5b561o5y1w1xie7y74qzpfik7kyi2yfqr...@bounce.linkedin.com
Received: from mailb-de.linkedin.com (mailb-de.linkedin.com [108.174.6.157])
 by sync.recvdomain.com (Postfix) with ESMTP id 3561F1A4C04
 for ; Sun, 2 Oct 2016 20:10:31 +0530 (IST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linkedin.com;
 s=proddkim1024; t=1475419164;
 bh=0BGcec8gfa2UUrhh3rWJw+dpo9wKPor0X6Nmr4swfos=;
 h=From:Subject:MIME-Version:Content-Type:To:Date:X-LinkedIn-Class:
  X-LinkedIn-Template:X-LinkedIn-fbl;
 b=o/PNleMe51U0pZDfW/LAVdNKiv2C4ovHt5yvMj1yrIhPfRBMKGtcGYSk67Vfl7CKx
  sHutanfc5qs/eUEKnE3kMH5d2ErQ6PrVf89XBoQJtdLTOkMAAi7xEMFeE3FG0kY7Dw
  otmGefhsAJezAVhhv0enUvM5Lho7jEcJ3xFcksls=
From: John Kennedy 
Message-ID: 
<401079548.70154.1475419164807.javamail@lva1-app2439.prod.linkedin.com>
Subject: Abc, please add me to your LinkedIn network
MIME-Version: 1.0
Content-Type: multipart/alternative;
 boundary="=_Part_70152_1116365500.1475419164803"
To: Abc Ganta 
Date: Sun, 2 Oct 2016 14:39:24 + (UTC)
X-LinkedIn-Class: INVITE-MBR
X-LinkedIn-Template: email_m2m_invite_single_01
X-LinkedIn-fbl: 
m2-at007hio5vmhecl55aegbrldj55dod8ekz33kb3ea8tqs5z1y4pek73m8v82dh9r3w53jdybhoksmyfs6cs0g1gofydssh0dlrpf0p
X-LinkedIn-Id: 2j1zjf-itsqh361-p8
List-Unsubscribe: 

Require-Recipient-Valid-Since: a...@recvdomain.com; Wed, 14 Aug 2013 00:00:00 
+


From:


s-2gvpcup5oqbkzh2ybkjw5b561o5y1w1xie7y74qzpfik7kyi2yfqr...@bounce.linkedin.com







Regards

Durga Prasad





[Avast logo] 


This email has been checked for viruses by Avast antivirus software.
www.avast.com


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

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

Re: [dmarc-discuss] exegesis: pass and fail together

[Roland Turner via dmarc-discuss]

Hi Thomas,

It's not immediately clear from your edits whether the results that you are 
showing are from the same  of the DMARC report; my guess is that they're 
not. Assuming that my guess is correct: it's worth bearing in mind that a DMARC 
aggregate report is just that: a report aggregating information about all of 
the email messages that the Receiver has seen purporting to be from your 
organisation during the report period (almost always 24 hours). To keep things 
at a reasonable size, the report groups message reports that have identical 
dispositions etc. into a single  with a , instead of providing a 
row per message. When interpreting the report, it is important to view each 
 as though it were a completely separate report from the same Receiver.

The other thing that occasionally creates confusion is the difference between:

- the authentication results (whether a particular authentication evaluation 
returned true or false at the SPF/DKIM level), and
- the effective authentication result when evaluating policy (a pass for an 
unrelated domain will be treated as a fail for DMARC evaluation purposes; 
similarly parent vs. child domains if you're using different policies for 
sub-domains).

- Roland

--
From: dmarc-discuss  on behalf of Thomas 
Krichel via dmarc-discuss 
Sent: Tuesday, 5 July 2016 15:41
To: DMARC-discuss
Subject: [dmarc-discuss] exegesis: pass and fail together
    

  Hi gang,

  I am new to DMARC. Google have sent me a report that I attach.
  I am puzzled by what I am reading. About DKIM


  openlib.org
  pass


  openlib.org
  fail


  How can it fail and pass at the same time?
  Then about SPF


 
 2a01:4f8:190:62e8::68
 7
 
  none
  pass
  fail
 
 
  
  openlib.org
  
  

  ...
  
  
   lists.openlib.org
   pass
  



  How can it say that the SPF fails in the policy evaluated,
  but later say it passes. Could this be me posting to a mailing
  list, with the from: saying kric...@openlib.org, but forwarded
  by lists.openlib.org? 2a01:4f8:190:62e8::68 is SPF authorized to
  send mail for both lists.openlib.org and openlib.org, so this
  would still be puzzling. 

-- 

  Cheers,

  Thomas Krichel  http://openlib.org/home/krichel
  skype:thomaskrichel

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

[Roland Turner via dmarc-discuss]

Andreas Schulze wrote:

> 2)
> a general point I'm still unsure about:
>
> https://datatracker.ietf.org/doc/draft-ietf-dmarc-arc-usage say in 2.)
>
>> "If the mailing list implemented ARC, ..."
>
> ARC *require* the list operator (Intermediary) to install new or update 
> existing - right?

No. ARC seeks to construct a situation in which forwarders and receivers will 
each gain incremental benefit if they choose to implement; it neither requires 
nor assumes implementation by any particular participant.

> But the list operators fail over the last years to do so. Why should I expect 
> they will do now?

List operators typically cite two compelling reasons for not making changes to 
support pre-ARC schemes:

1) the assumption that they're being asked to expend resources to solve someone 
else's problems; and
2) even if resource constraints are ignored, each of the proposed changes 
imposes harmful dilemmas (each option, including do nothing, is harmful).

ARC directly addresses (2). Unlike the measures for interoperating with earlier 
schemes, adding an ARC-* header set does not in any way impede or alter the 
traditional operation of mailing lists. Consequently: if list operators 
perceive benefit in implementing ARC, then they're free to do so without having 
to incur additional operational problems, in particular without changing user 
experience.

(1) is not a big problem; for a list operator who doesn't have a problem that 
ARC addresses there is no reason for them to implement ARC, and it doesn't 
matter to anyone else if they don't.

- Roland



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

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

Re: [dmarc-discuss] DMARC and null path

[Roland Turner via dmarc-discuss]

Scott Kitterman wrote:

>> Am 13.05.2016 um 22:35 schrieb Terry Zink via dmarc-discuss:
>>> In Office 365 it would. Others' implementations may vary.
>>
>> "may or may not" - is that really the intention of DMARC?
>
> I think RFC 7489, paragraph 3.1.2 is very explicit about this.  It is 
> supposed to pass and if it doesn't it's a bug.

It would appear to me that it is that paragraph which acknowledges, explicitly, 
that this is not so. It says:

   Note that the RFC5321.HELO identity is not typically used in the
   context of DMARC (except when required to "fake" an otherwise null
   reverse-path), even though a "pure SPF" implementation according to
   [SPF] would check that identifier.

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

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

Re: [dmarc-discuss] DMARC and null path

[Roland Turner via dmarc-discuss]

A. Schulze wrote:

> Am 13.05.2016 um 22:35 schrieb Terry Zink via dmarc-discuss:
>> In Office 365 it would. Others' implementations may vary.
>
> "may or may not" - is that really the intention of DMARC?

That is how DMARC is specified, yes. Intention is a bit harder:

- the ideal is that all implementations yield the same results, however
- at the time DMARC was publicised it was acknowledged, explicitly, that 
implementations would be variable (in part because of their dependence upon 
various underlying implementations of SPF and DKIM, and even more variable 
integrations with those implementations) but that it was better that each 
participant made best use of the information that they had available given the 
limitations of their existing systems, rather than that a much lower bar was 
set for functionality by requiring uniform behaviour.

It's worth bearing in mind the context in which DMARC came into being: a full 
decade (2003 SPF - 2013 DMARC) had gone into trying to solve the problem with 
little/no success. Part of the success of DMARC was that it took a more 
pragmatic approach, including tolerance of variable behaviour by receivers.

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

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

Re: [dmarc-discuss] is that *really* valid

[Roland Turner via dmarc-discuss]

Franck Martin wrote:

> Even in this case Lastname is not a valid mailbox as it does not have a valid 
> email address,

That is my interpretation also. The ability of many MTAs to work with implicit 
domains internally is outside 5322's scope.

- Roland



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

Franck Martin via dmarc-discuss:

 Vladimir,

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

Franck,

that's the point.

The message in question look like an auto-response from Yahoo!.
I *assume* it should only have one sender but due to $something there where 
quotes missing.
I'll forward the message headers to Yahoo! off-list.

Anyway, as this message was valid per RFC 5322 but invalid per RFC 7489
OpenDMARC correctly rejected that message. No bug so far.

Thanks!


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

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

Re: [dmarc-discuss] please clarify

[Roland Turner via dmarc-discuss]

Andreas Schulze wrote:

> Roland Turner via dmarc-discuss:
>
>> Yes. In all of the cases above, the Organizational Domain for both
>> RFC5322.From and the DKIM/SPF authentication is example.com,
>> consequently they match in relaxed mode. The same would be true for:
>>
>> - RFC5322.From: a.example.com
>> - DKIM or SPF authentication identifier: b.example.com
>>
>> Consideration 10.4 is exactly about what happens when independent
>> and/or potentially hostile parties have control of sub-domains.
>
> Thanks. That was new to me.
> Why was DMARC defined in that way?

That question has rather a large answer, parts of which span a decade of work 
on email authentication. It might perhaps be simpler to address the situation 
that's concerning you. Are you facing a specific situation for which this 
creates a problem?

- Roland

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

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

Re: [dmarc-discuss] please clarify

[Roland Turner via dmarc-discuss]

Andreas Schulze wrote:

> Roland Turner via dmarc-discuss:
>
>> Yes. In all of the cases above, the Organizational Domain for both
>> RFC5322.From and the DKIM/SPF authentication is example.com,
>> consequently they match in relaxed mode. The same would be true for:
>>
>> - RFC5322.From: a.example.com
>> - DKIM or SPF authentication identifier: b.example.com
>>
>> Consideration 10.4 is exactly about what happens when independent
>> and/or potentially hostile parties have control of sub-domains.
>
> Thanks. That was new to me.
> Why was DMARC defined in that way?

That question has rather a large answer, parts of which span a decade of work 
on email authentication. It might perhaps be simpler to address the situation 
that's concerning you. Are you facing a specific situation for which this 
creates a problem?

- Roland

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

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

Re: [dmarc-discuss] please clarify

[Roland Turner via dmarc-discuss]

A. Schulze wrote:

> I have a question about DMARC alignments.
>
> the usual case:
>  - RFC5322.From: sub.example.com
>  - DKIM or SPF authentication identifier: example.com
>
> -> this is aligned in relax mode.
>
> But:
>  - RFC5322.From: example.com
>  - DKIM or SPF authentication identifier: sub.example.com
>
> Is this a relax alignment?
> At least https://tools.ietf.org/html/rfc7489#section-10.4 suggest it is.

Yes. In all of the cases above, the Organizational Domain for both RFC5322.From 
and the DKIM/SPF authentication is example.com, consequently they match in 
relaxed mode. The same would be true for:

- RFC5322.From: a.example.com
- DKIM or SPF authentication identifier: b.example.com

Consideration 10.4 is exactly about what happens when independent and/or 
potentially hostile parties have control of sub-domains.

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

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

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

[Roland Turner via dmarc-discuss]

Ben Greenfield wrote:

> I believe the IP and hostname match exactly the ip address and hostname of 
> the working DKIM, SPF. I was assuming that these were the emails that went to 
> list-serves, but on further consideration if they were list-servs that would 
> show the ip and hostname of the list-serv.

DKIM and IP addresses are almost orthogonal, so the sorts of matches that 
you're talking about are not that important. Relevant questions would appear to 
be:

- Which IP addresses are sending messages that are failing DKIM but passing 
SPF[1]?
- Are these IP addresses under your control?
- If so, why is DKIM failing?
- If not, why are they listed in your SPF record?

- Roland

1: I assume that we're talking about SPF for your own domains, rather than for 
a forwarder's?
___
dmarc-discuss mailing list
dmarc-discuss@dmarc.org
http://www.dmarc.org/mailman/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

[Roland Turner via dmarc-discuss]

(merging two sub-threads)

Scott Kitterman wrote:

> Along with the good things you (quite reasonably) describe, there will also be
> an increased tendency towards concentration of power in a few hands. 
> Personally, I think that's a bad thing.  Your previous message in this thread
> captured my concern very nicely.

I'd suggest that the tendency towards concentration once uncertainty about the 
best way to do a thing subsides is perfectly ordinary and not something to be 
any more upset about than the tides, even if you were the kind of person who 
enjoyed building ornate sandcastles. The important concern would not be 
consolidation per se, but consolidation to the point where independent actors 
in related spheres lose their independence as a result. I don't believe that 
this result has arisen in the case of SMTP reputation data and see no reason to 
assume that it will arise with ARC reputation data (indeed, as described below, 
I believe it to be less likely in the ARC case).

> Roland Turner wrote:
>
>> I meant to ask earlier: would you level the same criticism at SMTP, given
>> that running a useful mail-receiving-server without a solid DNSBL is now
>> more-or-less infeasible? Does the fact that Spamhaus is already available
>> free of charge to all of the small guys change this analysis?
>
> The fact that there are high quality services available free/reasonable for a
> little guy to pay does alter my perspective.  At the time  DNSBLs were
> becoming popular/necessary there wasn't the same level of concentration in the
> market and even going back to open relay lists there's ~always been something
> anyone on a modest budget could use.

So, looking forward a couple of steps: when/if ARC proves to be useful (bear in 
mind that it's currently untested) it would seem to me to be a near certainty 
that the first and probably both of the following will occur:

- open-source MTAs/tools will gain the capability to make sensible use of ARC 
in DMARC decision-making, and
- reputation data providers will provide the "batteries" (assuming that there 
are important pieces that are too fast moving to be embedded in source code) 
just as they already do for DNSBLs.

You've not advanced any argument to suggest that this is not true, yet much of 
your concern appears to assume that it's not true. Do you believe that there's 
something special about ARC reputation data (mapping the observed behaviour of 
a few thousand well-intentioned forwarders who are not trying to hide) that is 
somehow more difficult, or less likely to appear than DNSBLs were and are 
(mapping the observed behaviour of hundreds of millions of IP addresses in the 
control of criminals who are working hard to hide what they're doing)? So far 
as I can tell, ARC reputation data will be a far simpler nut to crack than 
blocklists ever were, and may even be slow enough moving that it can be 
embedded in source code.

Stated another way, you appear to be making an extraordinary claim not merely 
in the absence of extraordinary evidence, but in the face of contradictory 
evidence.

>> Perhaps the fact that SMTP was developed at a time that abuse was not
>> widespread gives it a free pass on this front? Presumably you don't argue
>> that, *because* we're already in a high-abuse environment we should
>> therefore cease collaboration on any class of solution which happens to
>> require more data than is either: (a) feasible for small guys to process
>> usefully, or
>> (b) available to small guys at all?
>
> SMTP has always been, with a little study, been something any competent admin
> could do.  It takes a lot more study and more resources than a decade or two
> ago, but we haven't, in my opinion, crossed a tipping point where that's not
> longer possible.  So SMTP gets a pass because it's ~always been accessible (I
> know in the dim reaches of history that wasn't quite always so).

OK, but that wasn't quite the question that I meant to ask. I was getting at 
the dependence that we all have upon DNSBL providers. Generating that data is 
already out of range for all but about a dozen organisations in the world 
(there are multiple publicly-available products, but there's also a lot of 
licensing going on behind the scenes). ARC reputation data is likely to be 
easier produce (a smaller number of assessed entities, that are slower-moving, 
and aren't hiding themselves). How is it OK for SMTP use to be dependent upon 
DNSBLs but not for ARC use to be dependent upon reputation data?

If the issue is only that cheap/free ARC reputation data is not yet available - 
and noting the likelihood of its being easier to produce - surely this should 
currently be viewed as a transition state rather than a serious problem?

> I think solutions feasible for one segment of the market (large, small,
> purple, blue, don't care) are fine to collaborate on as long as people are
> clear it's a partial solution.

The authors (and most implementers) of both DMARC and ARC 

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

[Roland Turner via dmarc-discuss]

Franck Martin wrote:

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

They may or may not. (Analysing Received: headers to learn about forwarding 
behaviour is not an obviously important input for those organisations at 
present and, consequently, is something that they're probably not doing much 
of.) I'd suggest that the important question is whether they're likely to be 
willing to publish data to support ARC-enabled DMARC decision-making once (a) 
good ways of doing so are known and (b) fast-moving pieces that are worth 
delivering this way have been identified.

I'd guess "yes", but we're not yet at the point where we know that either of 
those assumptions is true.

- Roland

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

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

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

[Roland Turner via dmarc-discuss]

Scott Kitterman wrote:

> To
> the extent ARC is useful to mitigate the DMARC mailing list issue, it's only
> useful with additional data inputs that are not public and are not feasible
> for small providers to generate on their own.

I meant to ask earlier: would you level the same criticism at SMTP, given that 
running a useful mail-receiving-server without a solid DNSBL is now 
more-or-less infeasible? Does the fact that Spamhaus is already available free 
of charge to all of the small guys change this analysis?

Perhaps the fact that SMTP was developed at a time that abuse was not 
widespread gives it a free pass on this front? Presumably you don't argue that, 
*because* we're already in a high-abuse environment we should therefore cease 
collaboration on any class of solution which happens to require more data than 
is either:
(a) feasible for small guys to process usefully, or
(b) available to small guys at all?

Would the public availability from a trustworthy source of data that makes it 
possible to use ARC to decide when to override DMARC policies[1] change your 
position?

- Roland

1: I *don't* believe that this would take the form of a whitelist. It's more 
like the ability to recognise changes in baseline behaviour by forwarders who 
may or may not be ARC signing. I suspect that John Levine's concerns about 
whitelists have some strength.
___
dmarc-discuss mailing list
dmarc-discuss@dmarc.org
http://www.dmarc.org/mailman/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 MUAs show, was introduction to the list-virtual

[Roland Turner via dmarc-discuss]

John Levine wrote:

> DMARC does an OK job when crooks use the exact domain name, which they
> stilll do a lot, but we still don't have a clue about what to do when
> they don't, other than trying to filter it because it looks evil, not
> because it sorta kinda looks like a domain name in someone else's
> DMARC record.

+1, not the FUSPP.

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

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

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

[Roland Turner via dmarc-discuss]

Scott Kitterman wrote:

> So I hear what you're saying, but it doesn't change my mind.  I guess if the
> large providers think this is useful, then meh, OK,

That would be the guys who receive more than half of the world's email? I would 
rank that slightly above "meh", but sure, for small guys it's not yet obvious 
what value ARC provides. I'd suggest a wait-and-see approach.

> but I think it's pretty
> clearly not for anyone else and I am a little surprised they don't have
> equally good ways to solve the problem already deployed.

The specific requirement is to be able to see the upstream path of a specific 
message, adding authenticatable trace information is the obvious way to do 
this. The big guys could have privately agreed and implemented a way to do so, 
but:

- they'd then be under pressure to document what they were doing anyway,
- they'd thereby deny themselves access to a body of expertise that's been 
helpful in refining the specification,
- they'd deny themselves the direct- and increased-adoption- benefits of uses 
of it being developed independently[1], and
- I suspect, they'd like small-to-mid-sized forwarders to adopt it - as it's 
they who create much of the grief for DMARC processing - which would not have 
been possible if it had remained a private specification.

- Roland

1: As you frequently point out, non-DMARC uses are out of scope here, however 
the increased likelihood of their existing in the context of an open standard 
rather than a closed one would appear relevant.
___
dmarc-discuss mailing list
dmarc-discuss@dmarc.org
http://www.dmarc.org/mailman/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

[Roland Turner via dmarc-discuss]

John Levine wrote:

>>I'd prefer:
>>
>>From: Foo list [Jane Smith] 
>>CC: Jane Smith 
>
> Given that most MUAs these days don't show the e-mail address
> at all, it's hard to see why that would be better.

Granted, it's a fine point.

>> 1: Reply-To: appears to have become a third rail, I won't touch it.
>
> Oh, it's been a point of religious controversy for at least 20 years.
> I wouldn't touch it either, other than to note that adding a reply-to
> as a workaround to From: header workarounds rarely works the way
> you expect it to.

Quite.

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

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

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

[Roland Turner via dmarc-discuss]

John Levine wrote:

> How is this different from everyone's favorite alleged mailing list
> solution?
>
> From: Foo list on behalf of Jane Smith 
...
> PS: well, other than it's a little more explicit about where the
> responsibility lies

That is the difference.

I'd prefer:

From: Foo list [Jane Smith] 
CC: Jane Smith 

as "on behalf of" is a little too verbose but, yes, making sure that the 
distinction remains generally visible without:

- becoming extremely inconvenient (private replies become impossible because 
the author's email address is missing), or
- violating the principle of least astonishment[1] (wait, the list operator 
caused my private reply to be routed through his mail-server?)

is the point.

- Roland

1: Reply-To: appears to have become a third rail, I won't touch it.
___
dmarc-discuss mailing list
dmarc-discuss@dmarc.org
http://www.dmarc.org/mailman/listinfo/dmarc-discuss

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

Re: [dmarc-discuss] Sub-domain validation

[Roland Turner via dmarc-discuss]

Brotman, Alexander wrote:

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

No. You appear to be confusing the quoted example (merely one case) with the 
spec (all possible cases).

- For a relaxed match the spec merely requires that the organisational domains 
be the same (which is true in each of the cases that you describe).
- The quoted example merely describes one situation, that being what an example 
is. The fact that there are other cases that don't match the example above 
doesn't mean that they aren't supported.

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

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

Re: [dmarc-discuss] Experience 16 days with DMARC

[Roland Turner via dmarc-discuss]

I'd suggest a few things:

- You're looking a little too closely at daily changes, particularly around 
implementation time. Allow the thing some time to settle, perhaps a month, 
before considering next steps. Bear in mind that there are multiple, 
independent good and evil actors here, each reacting to the others all the 
time. This will take time to settle, a single day's (or week's) change is 
unlikely to be actionable. Note in particular that the larger receivers are 
almost certainly comparing their user feedback ("This is [not] Spam") with your 
DMARC policy ([un]authenticated messages that get reported as [not-]spam) as an 
input to their decision making. On the fairly small numbers that you're talking 
about, this calculation could take weeks to converge.
- The Forwarder and Threat/Unknown categories in Dmarcian are a mix of 
probabilistic assessments by email-receivers and by Dmarcian, not a reliable 
indication of what the email messages in question contain. They're interesting, 
but don't get hypnotised by them.
- How much is on-domain (vs. cousin-domain) impersonation costing you in 
fraud/support/churn losses? If it's costing you thousands of dollars a month, 
then by all means bring in the professionals. If you can't price it, or you 
haven't done so yet, or it's a trivial amount, then you're probably done.

- Roland


Roland Turner
Labs Director
Mobile: +65 9670 0022
3 Phillip Street, #13-03 Royal Group Building, Singapore 048693


www.trustsphere.com





From: dmarc-discuss  on behalf of Ben 
Greenfield via dmarc-discuss 
Sent: Sunday, 7 February 2016 18:42
To: dmarc-discuss
Subject: [dmarc-discuss] Experience 16 days with DMARC

First off I think DMARC is great and I’m happy with and want to try to use the 
information to protect my domain name.

I have been using dmarcian.com to analyze the reports and any terminology I use 
should be considered in the context of their tools. Their tools are all I know… 
so far.

Since I started receiving DMARC reports and tracked down a few specific domain 
names from DMARC reports to actual emails, I’m comfortable with most of the 
traffic I see in Forwarders categories and it’s great to see some with 100% 
DKIM survival.

I’m assuming that most of the servers in the category of forwarder are just 
moving mail around the world.

Threat/Unknown I take this to mean emails that have my domain in the from field 
and our trying to delivery the forged email.

This had fluctuated from around 4200 when I started on jan. 22nd to a low of 
1900 email on jan. 30th this had a steady climb of up to 5985 on feb. 4th 
before spiking to 15,516 on feb. 5th.

I see these fluctuations reflected in spam cop’s spam volume. Almost all the 
heavy traffic is coming from in order:

Vietnam
India
Brazil
UA
Russia


Is there anything I should be doing to try to clean up this problem?
Is DMARC the best I can do right now?

Thanks,
Ben





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

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

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

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

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

[Roland Turner via dmarc-discuss]

Scott,

You're [still!] confusing multiple conceptions of trust, including at least:

1) trust in the intention and ability of multiple upstream forwarders to 
ARC-sign correctly,
2) trust in the lack of intention to abuse by the organisation at the other end 
of the SMTP connection, and
3) trust in the intention and ability of the organisation at the other end of 
the SMTP connection to make exactly the same decision about disposition of a 
particular message (in fact: of all messages) as you would.

Implicit in (3) are two additional assumptions that may or may not be true:
a) that the organisation at the other end of the SMTP connection has exactly 
one level of confidence in message disposition (this is patently not true; 
larger senders/forwarders routinely maintain discernibly separate pools in 
order to help receivers make better choices), and
b) that you have exactly one level of confidence in message disposition (this 
may well be true of you personally as it is of me, but it certainly isn't for 
larger forwarders).

For larger receivers, the ability to see upstream (only possible when they 
trust at least one of the upstream intermediaries to ARC sign correctly) allows 
better decision-making (e.g. about DMARC overrides) than does your apparent 
"the organisation at the other end of the SMTP connection is good/bad" 
dichotomy. Note in particular that the ability to test ARC signatures from 
forwarders upstream of the organisation at the other end of the SMTP connection 
allows for DMARC overrides to happen, specifically, in the situation where the 
receiver doesn't trust the organisation at the other end of the SMTP 
connection. Adding ARC makes this possible more frequently than DMARC+SPF+DKIM 
does.

- Roland




Roland Turner
Labs Director
Mobile: +65 9670 0022
3 Phillip Street, #13-03 Royal Group Building, Singapore 048693


www.trustsphere.com





From: dmarc-discuss  on behalf of Scott 
Kitterman via dmarc-discuss 
Sent: Monday, 8 February 2016 03:43
To: dmarc-discuss@dmarc.org
Subject: Re: [dmarc-discuss] introduction to the list-virtual server &  mailman 
questions

To start with, you'll have to explain why receivers should trust a sender to
not lie about where they got the mail from in an ARC header field if they don't
already trust the sender.

Scott K

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

Re: [dmarc-discuss] Increase in Forwarders Since Implementation of DMARC Reject Policy

[Roland Turner via dmarc-discuss]

This would appear to be a Dmarcian question rather than a DMARC one as the 
Threat/Unknown is a Dmarcian classification rather than a DMARC one. More 
broadly, a/some receiver(s) and/or Dmarcian would appear to have decided at 
about the time that you made your change to reclassify a bunch of mail as 
forwarded. It is possible that this happened in response to your change, but 
I'd suggest rather unlikely.


If a receiver has decided to treat a particular message/stream as being from a 
trusted forwarder (i.e. to ignore the domain registrant's policy) then there is 
probably very little that you as a domain registrant can do to address that. If 
your total message volume is sufficient to warrant it then you might consider 
talking to AMI and/or Return Path about access to failure reports from the 
receivers in question and/or website deactivation services like IID.


(I have no current commercial relationship with any of the above.)


- Roland


[https://www.trustsphere.com/images/signatures/trustsphere.gif] Roland Turner
Labs Director
Mobile: +65 9670 0022
3 Phillip Street, #13-03 Royal Group Building, Singapore 048693


[https://www.trustsphere.com/images/signatures/facebook.gif]
[https://www.trustsphere.com/images/signatures/twitter.gif] 
   
[https://www.trustsphere.com/images/signatures/linkedin.gif] 
 
[https://www.trustsphere.com/images/signatures/youtube.gif] 
  
www.trustsphere.com






From: dmarc-discuss  on behalf of John Corey 
Miller via dmarc-discuss 
Sent: Tuesday, 26 January 2016 23:36
To: dmarc-discuss@dmarc.org
Subject: [dmarc-discuss] Increase in Forwarders Since Implementation of DMARC 
Reject Policy

We have Google Apps for Business set-up with our domain name for our business.

Since making the change to fully reject mail that fails dmarc, the number of 
messages counted as coming through "Forwarders" on our dmarc reports when run 
through this tool https://dmarcian.com/dmarc-xml/ has drastically increased.  
In many cases these new "Forwarders" are the same IPs that previously were 
coming through as "Threat/Unknown" (clearly fishers.)

Does this mean that after seeing that google started rejecting their e-mails 
they changed something about how they're sending them to attempt to circumvent 
these rejections?  If so, does any action have to be taken to prevent this 
circumvention?
___
dmarc-discuss mailing list
dmarc-discuss@dmarc.org
http://www.dmarc.org/mailman/listinfo/dmarc-discuss

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

Re: [dmarc-discuss] rddmarc & comcast reports

[Roland Turner via dmarc-discuss]

Yes, the slash is mandatory. From RFC 2045 5.1:


 content := "Content-Type" ":" type "/" subtype
*(";" parameter)
; Matching of media type and subtype
; is ALWAYS case-insensitive.

- Roland


Roland Turner | Labs Director
Singapore | M: +65 96700022
roland.tur...@trustsphere.com




From: dmarc-discuss  on behalf of Murray 
Kucherawy via dmarc-discuss 
Sent: Thursday, 12 November 2015 07:05
To: A. Schulze; dmarc-discuss@dmarc.org
Subject: Re: [dmarc-discuss] rddmarc & comcast reports

That has to be a syntax error.

On 11/10/15, 12:02 AM, "dmarc-discuss on behalf of A. Schulze via
dmarc-discuss"  wrote:

>
>Hello,
>
>I noticed last week rddmarc fail to read aggregated reports from Comcast.
>They send an unusual Content-Type: application-x-gzip;
>No idea if that's right or wrong. The attached patch extend rddmarc to
>import
>these reports.
>
>Andreas


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

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

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

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

Re: [dmarc-discuss] Neebie Questions about Spoofing Prevention and DMARC implementation

[Roland Turner via dmarc-discuss]

Hi Marc,


Largely echoing others:


  *   This is not a one-week project, you'll be lucky if it's a one-quarter 
project. To get to a steady state you have to (a) work with every 3rd-party 
sender used by every business unit in every country in which the companies do 
business, a non-zero fraction of whom won't [prefer to] speak English and (b) 
establish working procedural changes for all future uses of email worldwide 
that include establishing adequate authentication as part of every 3rd-party 
sender engagement.
  *   Get expert help! There are many pitfalls, you are probably better off 
learning from a consultant with relevant experience than from angry business 
units whose revenues you just disrupted...
  *   Definitely pilot with a few domains. Also take for granted the need to 
set different policies for different domains as you get authentication coverage 
up to an acceptable level at different times for different domains.
  *   Survey the available tools. A small investment of time now will save you 
a lot of lost time and disrupted business later. Dmarcian is good. Agari is 
good. I assume Return Path is good. I have probably offended several people by 
forgetting about other excellent options.
  *   Yes, you can send feedback for many domains to a single domain, but there 
is an access control protocol: the domain receiving all of the feedback has to 
publish specific additional DNS records to authorise 
mail-receivers/feedback-senders to send to an address in that domain (otherwise 
DMARC would provide a DDoS vector). All of the DMARC-feedback-analysis service 
providers provide destination addresses with this already set up, all of the 
large receivers performing DMARC processing will honour this when sending 
feedback.


Good luck!


- Roland


[http://www.trustsphere.com/images/signatures/trustsphere.png]
 Roland Turner | Labs Director
Singapore | M: +65 96700022
roland.tur...@trustsphere.com





From: dmarc-discuss  on behalf of Marc 
Luescher via dmarc-discuss 
Sent: Wednesday, 4 November 2015 19:48
To: dmarc-discuss@dmarc.org
Subject: [dmarc-discuss] Neebie Questions about Spoofing Prevention and DMARC 
implementation


Hi there,

I am new to this mailing list but have the challenging task to implements SPF, 
DKIM and DMARC on Cisco Ironports for two extremely large worldwide companies 
with 100's of
e-mail domains each. To make things more challenging by end of next week as we 
are under heavy spoofing attacks.

So far we have implemented a lot of defensive mail filters on the Ironports to 
validation of domain, friendly names, AV, etc and are tagging all incoming 
e-mails so the end user can more
easily find them in his inbox under the following structure, witrh rules doing 
the work :

Inbox

--Internal
  TO only
  CC

--External
   Primary
   Trusted Partner
   Social (Facebook, Linkedin etc)
   Public (public mailers)
   Newsletters (tagged)
   Potential SPAM


It is my current understanding that the following order of things should be 
followed  :

a) Publish a DMARC record with a domain to collect feedback
b) Deploy SPF for the mail domains
c) Deploy DKIM for the mail domains

d) Monitor SPF, DKIM and DMARC
e) Implement DMARC policy to quarantain and/or reject

It is my plan to start doing this with 1 or maybe 2 domains to get going.

My questions now :

a) does this sound like a good plan ?
b) in regards to dmarc records you need to specify an email adress for replies, 
can this always be the same e-mail for all 100's e-mail domains ?
c) Did i miss something ?

I will be documenting this implementation and am happy to share for interested 
parties as it involved Notes, Outlook, Cloud, ironports and much more.

Thank you

Marc

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

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