Re: [dmarc-discuss] [!!Mass Mail]Re: Sub-domain validation

2016-02-10 Thread MH Michael Hammer (5304) via dmarc-discuss
I concur with Franck on this.

From: dmarc-discuss [mailto:dmarc-discuss-boun...@dmarc.org] On Behalf Of 
Franck Martin via dmarc-discuss
Sent: Tuesday, February 09, 2016 4:55 PM
To: Brotman, Alexander
Cc: dmarc-discuss@dmarc.org
Subject: [!!Mass Mail]Re: [dmarc-discuss] Sub-domain validation

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

On Tue, Feb 9, 2016 at 1:36 PM, Brotman, Alexander via dmarc-discuss 
> wrote:
Hello,

I have a question about how to interpret a message for DMARC validation, 
relating to section 3.1.1, specifically:

   To illustrate, in relaxed mode, if a validated DKIM signature
   successfully verifies with a "d=" domain of 
"example.com", and the
   RFC5322.From address is 
"ale...@news.example.com", the DKIM "d="
   domain and the RFC5322.From domain are considered to be "in
   alignment".  In strict mode, this test would fail, since the "d="
   domain does not exactly match the FQDN of the address.

We've encountered a situation where a sender has a DMARC record, and they've 
signed the message with "d=sub.example.com", and the 
5322 From Domain is "example.com".  The record does not 
specify an adkim value, so it should default to relaxed.

I'm reading the above as the "relaxed" selector should apply to 
"sub.example.com" and something like 
"foo.sub.example.com", but not to 
"example.com".  From the way the above reads, this part of 
the validation should fail as there isn't a valid DKIM signature available for 
the 5322 domain.  Is this correct?

Thank you

--
Alex Brotman
Engineer, Anti-Abuse
Comcast
x5364



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

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

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

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

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

2016-02-10 Thread John Levine via dmarc-discuss
>dmarc.fail is an interesting approach, however the spam filters aren't the 
>concern that's
>being raised here, user education is. Teach people that
>my.fri...@real.domain.some-unfamiliar-stuff is a reasonable email address to 
>receive
>email from (vs. teaching them to treat that as extremely suspicious) by 
>periodically
>having legitimate email arrive that way (and preferentially from 
>heavily-phished domains)
>and you incrementally help phishers.

How is this different from everyone's favorite alleged mailing list
solution?

 From: Foo list on behalf of Jane Smith 

R's,
John

PS: well, other than it's a little more explicit about where the
responsibility lies
___
dmarc-discuss mailing list
dmarc-discuss@dmarc.org
http://www.dmarc.org/mailman/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] DMARC reports

2016-02-10 Thread Peter Bowen via dmarc-discuss
Does anyone maintain a list of receivers known to send DMARC reports?  I 
enabled DMARC reporting for a domain we use for sending and have gotten reports 
so far from 126.com, AOL, Belgacom, CapitalOne, Cisco, Comcast, FastMail, 
Google, Infor, Microsoft, mail.ru, NetEase (163.com), QQ,and Yahoo.

From these reports, I’ve seen a number of different variations that do not 
follow the XML Schema in RFC 7489.  I know there is the DMARC WG at IETF, but I 
haven’t seen any updates on the core spec, so I’m hoping someone implementing 
DMARC may have sorted out what is considered acceptable.

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

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

Re: [dmarc-discuss] DMARC reports

2016-02-10 Thread Matt Vernhout via dmarc-discuss
This is a fairly good list of potential DMARC senders:
https://dmarcian.com/dmarc-status/

Cheers,

~
*MATT VERNHOUT*
Founder, Editor

EmailKarma.net 
It's not the size of your list, it's how you use it!

My profiles:  
  


On Wed, Feb 10, 2016 at 2:44 PM, Peter Bowen via dmarc-discuss <
dmarc-discuss@dmarc.org> wrote:

> Does anyone maintain a list of receivers known to send DMARC reports?  I
> enabled DMARC reporting for a domain we use for sending and have gotten
> reports so far from 126.com, AOL, Belgacom, CapitalOne, Cisco, Comcast,
> FastMail, Google, Infor, Microsoft, mail.ru, NetEase (163.com), QQ,and
> Yahoo.
>
> From these reports, I’ve seen a number of different variations that do not
> follow the XML Schema in RFC 7489.  I know there is the DMARC WG at IETF,
> but I haven’t seen any updates on the core spec, so I’m hoping someone
> implementing DMARC may have sorted out what is considered acceptable.
>
> Thanks,
> Peter
> ___
> dmarc-discuss mailing list
> dmarc-discuss@dmarc.org
> http://www.dmarc.org/mailman/listinfo/dmarc-discuss
>
> NOTE: Participating in this list means you agree to the DMARC Note Well
> terms (http://www.dmarc.org/note_well.html)
___
dmarc-discuss mailing list
dmarc-discuss@dmarc.org
http://www.dmarc.org/mailman/listinfo/dmarc-discuss

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

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

2016-02-10 Thread John Levine via dmarc-discuss
>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.

>- violating the principle of least astonishment[1] (wait, the list operator 
>caused my
>private reply to be routed through his mail-server?)

You must know different users than I do.  Most of them have no idea
how their mail gets from them to their correspondents, and I don't
recall any of them asking unless something screwed up and it got lost.
A great deal of mail to various domains ends up at gmail, and they
don't seem to have any trouble with that.  Data point: I've been doing
the dmail.fail rewrite for the better part of a year, I've had exactly
one user ask what it was, and when I explained it was to get around
some overeager filtering at large ISPs, they thought that was fine.

R's,
John

PS:

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

2016-02-10 Thread 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

2016-02-10 Thread 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] Experience 16 days with DMARC

2016-02-10 Thread Ben Greenfield via dmarc-discuss

> On Feb 10, 2016, at 1:55 AM, Roland Turner via dmarc-discuss 
>  wrote:
> 
> 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.

DMARC certainly provides another view into what is happening. I think what you 
are saying is that my small traffic volume 15,000 messages are such a small 
blip in the spammers world they will be doing some monthly analysis to notice 
and adjust their routine accordingly.

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

Yes, I have tracked legitimate emails through all the Dmarcian categories.

> They're interesting, but don't get hypnotised by them.

Looking forward to a drop off in traffic to break the spell...

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

That is good to know since nobody is directly paying to do this. I imagine that 
I should just keep an eye on ARC and I could always become an early adopter of 
that as way to improve things.


Thank you for taking the time to give me some perspective.

Ben


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


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

2016-02-10 Thread Scott Kitterman via dmarc-discuss
On Wednesday, February 10, 2016 07:17:31 AM Roland Turner via dmarc-discuss 
wrote:
> 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.

I see your point, but I'm still not sure what it buys you.  Without your #2, 
#1 is irrelevant, and #3 is, given #2, not a big deal I don't think.  As for 
a) and b), while that's certainly true (that large senders have different 
levels of quality messages sent from different pools), that's trivially 
discernible from IP reputation data if you have a large volume of it.

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

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)


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

2016-02-10 Thread 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] introduction to the list-virtual server & mailman questions

2016-02-10 Thread Steve Atkins via dmarc-discuss

> On Feb 10, 2016, at 6:37 PM, Roland Turner via dmarc-discuss 
>  wrote:
> 
> John Levine wrote:
> 
>> How is this different from everyone's favorite alleged mailing list
>> solution?
>> 
>> From: Foo list on behalf of Jane Smith 
> ...
>> PS: well, other than it's a little more explicit about where the
>> responsibility lies
> 
> That is the difference.
> 
> I'd prefer:
> 
>From: Foo list [Jane Smith] 
>CC: Jane Smith 
> 
> as "on behalf of" is a little too verbose but, yes, making sure that the 
> distinction remains generally visible without:
> 
> - becoming extremely inconvenient (private replies become impossible because 
> the author's email address is missing), or
> - violating the principle of least astonishment[1] (wait, the list operator 
> caused my private reply to be routed through his mail-server?)

Given that the important identifier is often the email address (“Which Bob are 
you?”, “Who is your employer?”) I think that any approach that intentionally 
obscures the actual author in that way is less than ideal.

From: Steve Atkins st...@blighty.com 

or 

From: Steve Atkins st...@blighty.com