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

[Ben Greenfield via dmarc-discuss]

> On Feb 17, 2016, at 2:05 AM, Roland Turner via dmarc-discuss 
>  wrote:
> 
> 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]?

The ip address and server name are identical to each other come pass DKIM and 
some fail with  d=none.
It could be mail that is sent out using postfix only. The messages are missing 
the signature process which is in amavisd.

> - Are these IP addresses under your control?
Yes

> - If so, why is DKIM failing?

Signing doesn’t happen because the mail is sent directly by postfix.


> - If not, why are they listed in your SPF record?


Yes.

Thanks for your help. Do you think that is correct. Should I look into either 
sending getting the message to amavisd before sending or add signing to postfix.



Thanks,


Ben

> 
> - Roland
> 
> 1: I assume that we're talking about SPF for your own domains, rather than 
> for a forwarder’s?


I keep insisting that I have no forwarders but I realize I should clarify I 
have a single mail server in a single location. I do plan on adding a second 
location but I want to square this basic install before I try that.






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


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

[Ben Greenfield via dmarc-discuss]

I keep forgetting the most important clue to the whole thing. The domains that 
are failing the DKIM are 


google.com
AOL
Yahoo! Inc.

Which is why I thought it must be list-serv traffic.

Ben


> On Feb 17, 2016, at 2:05 AM, Roland Turner via dmarc-discuss 
>  wrote:
> 
> 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)


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

[Ben Greenfield via dmarc-discuss]

> On Feb 16, 2016, at 12:43 AM, Roland Turner via dmarc-discuss 
>  wrote:
> 
> Franck Martin wrote:
> 
>> Yes it is a "you have to be this tall to ride with us". For instance, many
>> Wordpress sites are on URL blocking lists, because the managers
>> cannot keep with basic security updates. So if you want to host a website,
>> you have to be that tall to  ride with us (or find a hosting company, that 
>> will
>> give you a child seat)
> 
> This is not quite the concern that Scott is raising. He's not concerned so 
> much about absentee administrators being unable to keep their services from 
> being compromised and therefore becoming unusable/blocked, but about actively 
> engaged administrators for any email receiving service other than those 
> operated by the big 3 being, eventually, unable to operate effectively. We're 
> not there yet, and I'm more optimistic then Scott is in that I don't think 
> it's anywhere near a foregone conclusion, but the concern is a real one and 
> worth keeping an eye on.

It was that concern that brought my 1 horse email server to DMARC & SPF. I 
think eventually ARC.

I was little surprised in watching the ARC conversation because it was my 
thinking that ARC was going to provide a way mid-email delivery for the 
receiving mail server to check the validity of the email with the sending 
server.

I though the sending server would keep track of what it sent and any receiver 
could check the validity. I thought that we have finally reached the point 
where tracking every legitimate email was easier then weeding through all the 
crap.

Ben









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

[Franck Martin via dmarc-discuss]

On Mon, Feb 15, 2016 at 10:53 PM, Scott Kitterman via dmarc-discuss
 wrote:
> On Tuesday, February 16, 2016 06:17:27 AM Roland Turner via dmarc-discuss
> wrote:
>> Scott Kitterman wrote:

>>
>> 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.
>
> It would as that data is the barrier to entry I'm worried about.  I think it's
> actually two lists:
>
> 1.  Domains good enough you ought to trust to believe what they say in ARC.
> 2.  Domains bad enough you ought to reject their mail if they show up in ARC.
>
> I do wonder though if I have the data to toss the message why they didn't in
> the first place (and if they didn't why I should trust them).  So generically,
> yes, but I'm not certain what the characteristics of such a data source would
> be.
>

I looked at spamassassin and they don't do this work: take all the
domains in From, Reply-to, Sender, Dkim,... and evaluate them against
Domain Blocking lists and rejecting or scoring the email... they would
argue it is not a clear indicator of spam. Indeed, it has plenty false
positives but it obliges the domain owners to clean their domain or
practices... If I had the time to code some new spamassassin rules.

On the barrier to entry, I'm not sure an enterprise/organization can
run a mail system without some form of paid appliance/services to
filter out spam/phish/malware.

Yes I'm mindful that any clued admin should be able to run a mail
system. I don't think so far I have seen anyone making it impossible.
If you do the right things, your email can be sent and will be
accepted. The difficulty is how much spam you will be able to filter
for your incoming mail into your system. Paid services seems to
provide less risk.
___
dmarc-discuss mailing list
dmarc-discuss@dmarc.org
http://www.dmarc.org/mailman/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

[Scott Kitterman via dmarc-discuss]

On Tuesday, February 16, 2016 06:17:27 AM Roland Turner via dmarc-discuss 
wrote:
> 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?

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.

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

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.  

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

It would as that data is the barrier to entry I'm worried about.  I think it's 
actually two lists:

1.  Domains good enough you ought to trust to believe what they say in ARC.
2.  Domains bad enough you ought to reject their mail if they show up in ARC.

I do wonder though if I have the data to toss the message why they didn't in 
the first place (and if they didn't why I should trust them).  So generically, 
yes, but I'm not certain what the characteristics of such a data source would 
be.

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

[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

[Scott Kitterman via dmarc-discuss]

On Tuesday, February 16, 2016 06:02:31 AM Roland Turner via dmarc-discuss 
wrote:
> Scott Kitterman wrote:
> >> Roland Turner wrote:
> >> 
> >> This is just a diffusion process, not an exclusion of smaller players.
> >> Indeed, it would almost appear that you'd be happier if the big guys had
> >> excluded smaller players from this initiative...
> > 
> > Until maybe someday the results of the analysis to use ARC are somehow
> > available, they have.
> 
> All diffusion looks like this.
> 
> The "one size fits all" mentality gave us the lost decade. Recognising that
> differently-situated practitioners need different things and developing a
> range of tools/protocols/etc. to suit the range of needs (most of which
> will be not useful for most practitioners) is not merely more effective, it
> currently appears to be the only way forward.
> > The use of an open standard (which I am in favor of and
> > this is good), doesn't materially change that.  If I can write code to
> > implement a standard, but don't have the necessary inputs to use it, it's
> > not particularly of use.
> 
> "not particularly of use to Scott" != "not useful".
> 
> This is of course a different question to the one about whether/how to
> involve yourself, more below.
> > Personally, I try to consider putting my time where either I'll benefit
> 
> Eminently sensible, I do the same.
> 
> > or I think the global Internet will benefit.
> 
> Likewise, and so here's the challenge: the big guys hardening their part of
> the environment against criminals doesn't merely improve life for the big
> guys (e.g. by shifting criminals' focus elsewhere), they are so big that
> they are materially altering the economics in a way that makes crime less
> profitable and therefore less likely than it would otherwise be. This
> directly benefits the global Internet in a way that a
> batteries-included-but-less-impactful approach could not, even assuming
> that such an approach exists (are you aware of one?).
> 
> Do you really mean "or", or do you actually mean "and"? We are talking about
> an initiative that, if successful, will materially benefit the global
> Internet, even though you personally will not be able wield the resulting
> tool for some time, or possibly even ever (unlikely, but possible). Do you
> support it anyway?
> 
> (A less charitable interpretation is that your concern is merely resentment
> or envy of large organisations. Presumably this is not correct.)

No.  Not at all.  I do mean 'or'.  I quite routinely invest time in things to 
make the Internet work better that don't personally benefit me.  Obviously the 
greater the personal and systemic benefit the greater my motivation, but I 
certainly have and do work on things that don't help me in any way 
proportionate to the time I invest in it. 

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.

Thanks,

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

[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] introduction to the list-virtual server & mailman questions

[Franck Martin via dmarc-discuss]

The problem with the e-mail community, is few people drives all of us
away from mailing lists.

On Mon, Feb 15, 2016 at 3:47 PM, John R Levine  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.
>
>
> No, really, they don't.  Take it from someone who actually writes MTA
> software, and probably knows more than most people about what's in the DBL.
>
>
>>> ARC provides no protection against replay attacks, in particular,
>>> against taking a set of ARC headers from a benign message and sticking
>>> them on malware or spam.  (This isn't saying it's misdesigned, just
>>> that it does what it does.)
>>>
>>> That means that it only makes sense to evaluate ARC headers on mail
>>> from hosts that you believe are generally trustworthy.  Large mail
>>> systems have enough mail flow that they usually already have a pretty
>>> good idea who's trustworthy, small mail systems don't.
>>>
>>> I have a database that has logged every single connection to my MTA
>>> since 2008, and which mail was treated how, but that's still nowhere
>>> near enough to provide useful reputation info about sources other than
>>> ones that are so so large that I can just whitelist them anyway.
>>> Scott and I aren't saying the code's too hard to write, we can code
>>> anything we want to.  We don't have the data.
___
dmarc-discuss mailing list
dmarc-discuss@dmarc.org
http://www.dmarc.org/mailman/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

[Franck Martin via dmarc-discuss]

As I said earlier spamhaus and surbl has the data. The question is not
which domains to trust, but which domains not to trust.

On Mon, Feb 15, 2016 at 3:35 PM, John Levine  wrote:
>>ARC purpose is to say when DMARC fail and the email should be rejected that
>>it is ok to let it through. As such there is no scale problem and anyone
>>can do it.
>
> ARC provides no protection against replay attacks, in particular,
> against taking a set of ARC headers from a benign message and sticking
> them on malware or spam.  (This isn't saying it's misdesigned, just
> that it does what it does.)
>
> That means that it only makes sense to evaluate ARC headers on mail
> from hosts that you believe are generally trustworthy.  Large mail
> systems have enough mail flow that they usually already have a pretty
> good idea who's trustworthy, small mail systems don't.
>
> I have a database that has logged every single connection to my MTA
> since 2008, and which mail was treated how, but that's still nowhere
> near enough to provide useful reputation info about sources other than
> ones that are so so large that I can just whitelist them anyway.
> Scott and I aren't saying the code's too hard to write, we can code
> anything we want to.  We don't have the data.
>
> R's,
> John
___
dmarc-discuss mailing list
dmarc-discuss@dmarc.org
http://www.dmarc.org/mailman/listinfo/dmarc-discuss

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

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

[John Levine via dmarc-discuss]

>ARC purpose is to say when DMARC fail and the email should be rejected that
>it is ok to let it through. As such there is no scale problem and anyone
>can do it.

ARC provides no protection against replay attacks, in particular,
against taking a set of ARC headers from a benign message and sticking
them on malware or spam.  (This isn't saying it's misdesigned, just
that it does what it does.)

That means that it only makes sense to evaluate ARC headers on mail
from hosts that you believe are generally trustworthy.  Large mail
systems have enough mail flow that they usually already have a pretty
good idea who's trustworthy, small mail systems don't.

I have a database that has logged every single connection to my MTA
since 2008, and which mail was treated how, but that's still nowhere
near enough to provide useful reputation info about sources other than
ones that are so so large that I can just whitelist them anyway.
Scott and I aren't saying the code's too hard to write, we can code
anything we want to.  We don't have the data.

R's,
John
___
dmarc-discuss mailing list
dmarc-discuss@dmarc.org
http://www.dmarc.org/mailman/listinfo/dmarc-discuss

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

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

[Franck Martin via dmarc-discuss]

Spamhaus and SURBL both publish a domain blocking list, this is enough to
use to block emails that went through bad domains (as per ARC custody chain)

Of course, this has to be built into the MTA, but it is all opensource, it
is not out of reach, just volunteers and work...

On Mon, Feb 15, 2016 at 3:00 PM, Scott Kitterman via dmarc-discuss <
dmarc-discuss@dmarc.org> wrote:

> The difference in this case is one, maintaining a Wordpress site, requires
> a
> lot of vigilance, but no information/data that's not publicly available.
> 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.
>
> It's the difference between can, but often shouldn't and can't.
>
> I'll stop here though, the horse was probably dead a few mails ago.
>
> Scott K
>
> On Monday, February 15, 2016 02:11:57 PM Al Iverson via dmarc-discuss
> wrote:
> > Scott, I don't really see any difference in the class of problem. You
> could
> > choose to outsource email it to Google Apps or Microsoft Office 365 if
> you
> > don't want to figure this stuff out yourself. Many do, from SMB to
> > enterprise level, even though email is core to just about every company's
> > business. For some, that's very much the reason to job it out to a
> company
> > who focuses on email as an area of expertise.
> >
> > On the flip side, I disagree with regard to your take on running a blog.
> > Anybody can do it, but many people outsource that as well. I personally
> > host my blog with a third party service, because self-hosted Wordpress is
> > one of the most hacked into things out there and I want no part of that
> > noise, even though in theory I could handle it. I know I'm not the only
> > one, and just about anything in this paragraph could similarly apply to
> > email.
> >
> > Regards,
> > Al Iverson
> >
> >
> > --
> > Al Iverson - Minneapolis - (312) 275-0130
> > Simple DNS Tools since 2008: xnnd.com
> > www.spamresource.com & aliverson.com
> >
> > On Mon, Feb 15, 2016 at 1:35 PM, Franck Martin via dmarc-discuss <
> >
> > dmarc-discuss@dmarc.org> wrote:
> > > ARC purpose is to say when DMARC fail and the email should be rejected
> > > that it is ok to let it through. As such there is no scale problem and
> > > anyone can do it.
> > >
> > > If email is your core business, then complaining you have to do some
> work,
> > > will not give any sympathy.
> > >
> > > On Mon, Feb 15, 2016 at 11:17 AM, Scott Kitterman via dmarc-discuss <
> > >
> > > dmarc-discuss@dmarc.org> wrote:
> > >> That's a totally different class of problem.  Any competent sysadmin
> with
> > >> some
> > >> time can maintain a CMS based web site (e.g. Wordpress).  The fact
> that
> > >> so
> > >> many are not competently managed is a function of capability and
> > >> willingness
> > >> to do a little work, not a function of inadequate scale.
> > >>
> > >> Also, following that example, I choose to blog on wordpress.com,
> > >> specifically
> > >> so I don't have to worry about such things, but the blog isn't a core
> > >> business
> > >> function, so that's fine.  Email is more important, so I care more how
> > >> and
> > >> where it gets done.
> > >>
> > >> Scott K
> > >>
> > >> On Monday, February 15, 2016 10:56:57 AM Franck Martin via
> dmarc-discuss
> > >>
> > >> wrote:
> > >> > Yes it is a "you have to be this tall to ride with us". For
> instance,
> > >>
> > >> many
> > >>
> > >> > Wordpress sites are on URL blocking lists, because the managers
> cannot
> > >>
> > >> keep
> > >>
> > >> > with basic security updates. So if you want to host a website, you
> have
> > >>
> > >> to
> > >>
> > >> > be that tall to ride with us (or find a hosting company, that will
> give
> > >>
> > >> you
> > >>
> > >> > a child seat)
> > >> >
> > >> > The mail ecosystem is going this way too. The tools are opensource,
> > >> > available to all, but you need to deploy them and maintain them.
> > >> >
> > >> > The spat of serious data breaches because of email, is making all
> of us
> > >> > very nervous that kids can create so much havoc so easily...
> > >> >
> > >> > On Sun, Feb 14, 2016 at 11:27 PM, Roland Turner via dmarc-discuss <
> > >> >
> > >> > dmarc-discuss@dmarc.org> wrote:
> > >> > > Scott Kitterman wrote:
> > >> > > > It would be nice if we didn't design standards that only worked
> at
> > >> > > > a
> > >> > >
> > >> > > certain
> > >> > >
> > >> > > > scale.  "You must be this tall to ride" worries me.
> > >> > >
> > >> > > There's nothing about ARC that is scale-specific, except for the
> > >>
> > >> obvious
> > >>
> > >> > > observation that there's a batteries-not-included problem, so the
> > >>
> > >> analysis
> > >>
> > >> > > work required to make good use of it as a receiver is likely to be
> > >> > > infeasible for smaller receivers meaning that:
> > >> > >
> > >> > > - initially only larger receivers will do it, and
> > >> > > - if it 

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

[Scott Kitterman via dmarc-discuss]

The difference in this case is one, maintaining a Wordpress site, requires a 
lot of vigilance, but no information/data that's not publicly available.  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.

It's the difference between can, but often shouldn't and can't.

I'll stop here though, the horse was probably dead a few mails ago.

Scott K

On Monday, February 15, 2016 02:11:57 PM Al Iverson via dmarc-discuss wrote:
> Scott, I don't really see any difference in the class of problem. You could
> choose to outsource email it to Google Apps or Microsoft Office 365 if you
> don't want to figure this stuff out yourself. Many do, from SMB to
> enterprise level, even though email is core to just about every company's
> business. For some, that's very much the reason to job it out to a company
> who focuses on email as an area of expertise.
> 
> On the flip side, I disagree with regard to your take on running a blog.
> Anybody can do it, but many people outsource that as well. I personally
> host my blog with a third party service, because self-hosted Wordpress is
> one of the most hacked into things out there and I want no part of that
> noise, even though in theory I could handle it. I know I'm not the only
> one, and just about anything in this paragraph could similarly apply to
> email.
> 
> Regards,
> Al Iverson
> 
> 
> --
> Al Iverson - Minneapolis - (312) 275-0130
> Simple DNS Tools since 2008: xnnd.com
> www.spamresource.com & aliverson.com
> 
> On Mon, Feb 15, 2016 at 1:35 PM, Franck Martin via dmarc-discuss <
> 
> dmarc-discuss@dmarc.org> wrote:
> > ARC purpose is to say when DMARC fail and the email should be rejected
> > that it is ok to let it through. As such there is no scale problem and
> > anyone can do it.
> > 
> > If email is your core business, then complaining you have to do some work,
> > will not give any sympathy.
> > 
> > On Mon, Feb 15, 2016 at 11:17 AM, Scott Kitterman via dmarc-discuss <
> > 
> > dmarc-discuss@dmarc.org> wrote:
> >> That's a totally different class of problem.  Any competent sysadmin with
> >> some
> >> time can maintain a CMS based web site (e.g. Wordpress).  The fact that
> >> so
> >> many are not competently managed is a function of capability and
> >> willingness
> >> to do a little work, not a function of inadequate scale.
> >> 
> >> Also, following that example, I choose to blog on wordpress.com,
> >> specifically
> >> so I don't have to worry about such things, but the blog isn't a core
> >> business
> >> function, so that's fine.  Email is more important, so I care more how
> >> and
> >> where it gets done.
> >> 
> >> Scott K
> >> 
> >> On Monday, February 15, 2016 10:56:57 AM Franck Martin via dmarc-discuss
> >> 
> >> wrote:
> >> > Yes it is a "you have to be this tall to ride with us". For instance,
> >> 
> >> many
> >> 
> >> > Wordpress sites are on URL blocking lists, because the managers cannot
> >> 
> >> keep
> >> 
> >> > with basic security updates. So if you want to host a website, you have
> >> 
> >> to
> >> 
> >> > be that tall to ride with us (or find a hosting company, that will give
> >> 
> >> you
> >> 
> >> > a child seat)
> >> > 
> >> > The mail ecosystem is going this way too. The tools are opensource,
> >> > available to all, but you need to deploy them and maintain them.
> >> > 
> >> > The spat of serious data breaches because of email, is making all of us
> >> > very nervous that kids can create so much havoc so easily...
> >> > 
> >> > On Sun, Feb 14, 2016 at 11:27 PM, Roland Turner via dmarc-discuss <
> >> > 
> >> > dmarc-discuss@dmarc.org> wrote:
> >> > > Scott Kitterman wrote:
> >> > > > It would be nice if we didn't design standards that only worked at
> >> > > > a
> >> > > 
> >> > > certain
> >> > > 
> >> > > > scale.  "You must be this tall to ride" worries me.
> >> > > 
> >> > > There's nothing about ARC that is scale-specific, except for the
> >> 
> >> obvious
> >> 
> >> > > observation that there's a batteries-not-included problem, so the
> >> 
> >> analysis
> >> 
> >> > > work required to make good use of it as a receiver is likely to be
> >> > > infeasible for smaller receivers meaning that:
> >> > > 
> >> > > - initially only larger receivers will do it, and
> >> > > - if it works then, over time, vendors/developers will embed
> >> 
> >> slow-moving
> >> 
> >> > > pieces in products and/or reputation data providers will add faster
> >> 
> >> moving
> >> 
> >> > > pieces to their services.
> >> > > 
> >> > > This is just a diffusion process, not an exclusion of smaller
> >> > > players.
> >> > > Indeed, it would almost appear that you'd be happier if the big guys
> >> 
> >> had
> >> 
> >> > > excluded smaller players from this initiative...
> >> > > 
> >> > > I'd also point out that we spent most of a decade (2003 - 2011)
> >> 
> >> wandering
> >> 
> >> > > in a 

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

[Al Iverson via dmarc-discuss]

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

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

Regards,
Al Iverson


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

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

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

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

[Franck Martin via dmarc-discuss]

ARC purpose is to say when DMARC fail and the email should be rejected that
it is ok to let it through. As such there is no scale problem and anyone
can do it.

If email is your core business, then complaining you have to do some work,
will not give any sympathy.

On Mon, Feb 15, 2016 at 11:17 AM, Scott Kitterman via dmarc-discuss <
dmarc-discuss@dmarc.org> wrote:

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

[Scott Kitterman via dmarc-discuss]

That's a totally different class of problem.  Any competent sysadmin with some 
time can maintain a CMS based web site (e.g. Wordpress).  The fact that so 
many are not competently managed is a function of capability and willingness 
to do a little work, not a function of inadequate scale.

Also, following that example, I choose to blog on wordpress.com, specifically 
so I don't have to worry about such things, but the blog isn't a core business 
function, so that's fine.  Email is more important, so I care more how and 
where it gets done.

Scott K

On Monday, February 15, 2016 10:56:57 AM Franck Martin via dmarc-discuss 
wrote:
> Yes it is a "you have to be this tall to ride with us". For instance, many
> Wordpress sites are on URL blocking lists, because the managers cannot keep
> with basic security updates. So if you want to host a website, you have to
> be that tall to ride with us (or find a hosting company, that will give you
> a child seat)
> 
> The mail ecosystem is going this way too. The tools are opensource,
> available to all, but you need to deploy them and maintain them.
> 
> The spat of serious data breaches because of email, is making all of us
> very nervous that kids can create so much havoc so easily...
> 
> On Sun, Feb 14, 2016 at 11:27 PM, Roland Turner via dmarc-discuss <
> 
> dmarc-discuss@dmarc.org> wrote:
> > Scott Kitterman wrote:
> > > It would be nice if we didn't design standards that only worked at a
> > 
> > certain
> > 
> > > scale.  "You must be this tall to ride" worries me.
> > 
> > There's nothing about ARC that is scale-specific, except for the obvious
> > observation that there's a batteries-not-included problem, so the analysis
> > work required to make good use of it as a receiver is likely to be
> > infeasible for smaller receivers meaning that:
> > 
> > - initially only larger receivers will do it, and
> > - if it works then, over time, vendors/developers will embed slow-moving
> > pieces in products and/or reputation data providers will add faster moving
> > pieces to their services.
> > 
> > This is just a diffusion process, not an exclusion of smaller players.
> > Indeed, it would almost appear that you'd be happier if the big guys had
> > excluded smaller players from this initiative...
> > 
> > I'd also point out that we spent most of a decade (2003 - 2011) wandering
> > in a highly-inclusive -all/o=-/discardable wilderness. It took the world's
> > most-heavily-phished organisation working directly with one of the big
> > guys
> > in private to get any purchase on the problem, and their subsequent
> > sharing
> > of it (DMARC) to bring about progress more broadly. It would appear that
> > ARC is on a similar path to improving the situation for largest unresolved
> > piece of the problem (supporting forwarding). This does suggest a general
> > difficulty in using a consensus-driven process to devise solutions, rather
> > than merely refine/standardise/evolve them, however this does not seem
> > like
> > a reason for concern, it may simply indicate that we've gotten as far as
> > we
> > can get at present with such processes. The important test when deciding
> > whether to cooperate would appear to be whether the particular solution
> > unduly benefits the big guys compared to other viable solutions that are
> > already known about. !
> > 
> >  If there are none, then cooperating on ARC would appear to be a
> > 
> > no-brainer.
> > 
> > > Solving the mailing list 'problem' in a way that requires me to switch
> > > to
> > > gmail (or some other large scale provider) to get my list mail delivered
> > 
> > is
> > 
> > > worse than no solution at all for me.
> > 
> > Obviously. This is not being proposed, see the comments about about
> > vendors/developers and reputation data providers.
> > 
> > - 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] introduction to the list-virtual server & mailman questions

[Franck Martin via dmarc-discuss]

Yes it is a "you have to be this tall to ride with us". For instance, many
Wordpress sites are on URL blocking lists, because the managers cannot keep
with basic security updates. So if you want to host a website, you have to
be that tall to ride with us (or find a hosting company, that will give you
a child seat)

The mail ecosystem is going this way too. The tools are opensource,
available to all, but you need to deploy them and maintain them.

The spat of serious data breaches because of email, is making all of us
very nervous that kids can create so much havoc so easily...

On Sun, Feb 14, 2016 at 11:27 PM, Roland Turner via dmarc-discuss <
dmarc-discuss@dmarc.org> wrote:

> Scott Kitterman wrote:
>
> > It would be nice if we didn't design standards that only worked at a
> certain
> > scale.  "You must be this tall to ride" worries me.
>
> There's nothing about ARC that is scale-specific, except for the obvious
> observation that there's a batteries-not-included problem, so the analysis
> work required to make good use of it as a receiver is likely to be
> infeasible for smaller receivers meaning that:
>
> - initially only larger receivers will do it, and
> - if it works then, over time, vendors/developers will embed slow-moving
> pieces in products and/or reputation data providers will add faster moving
> pieces to their services.
>
> This is just a diffusion process, not an exclusion of smaller players.
> Indeed, it would almost appear that you'd be happier if the big guys had
> excluded smaller players from this initiative...
>
> I'd also point out that we spent most of a decade (2003 - 2011) wandering
> in a highly-inclusive -all/o=-/discardable wilderness. It took the world's
> most-heavily-phished organisation working directly with one of the big guys
> in private to get any purchase on the problem, and their subsequent sharing
> of it (DMARC) to bring about progress more broadly. It would appear that
> ARC is on a similar path to improving the situation for largest unresolved
> piece of the problem (supporting forwarding). This does suggest a general
> difficulty in using a consensus-driven process to devise solutions, rather
> than merely refine/standardise/evolve them, however this does not seem like
> a reason for concern, it may simply indicate that we've gotten as far as we
> can get at present with such processes. The important test when deciding
> whether to cooperate would appear to be whether the particular solution
> unduly benefits the big guys compared to other viable solutions that are
> already known about. !
>  If there are none, then cooperating on ARC would appear to be a
> no-brainer.
>
> > Solving the mailing list 'problem' in a way that requires me to switch to
> > gmail (or some other large scale provider) to get my list mail delivered
> is
> > worse than no solution at all for me.
>
> Obviously. This is not being proposed, see the comments about about
> vendors/developers and reputation data providers.
>
> - 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] introduction to the list-virtual server & mailman questions

[Scott Kitterman via dmarc-discuss]

On Monday, February 15, 2016 07:27:21 AM Roland Turner via dmarc-discuss 
wrote:
> Scott Kitterman wrote:
> > It would be nice if we didn't design standards that only worked at a
> > certain scale.  "You must be this tall to ride" worries me.
> 
> There's nothing about ARC that is scale-specific, except for the obvious
> observation that there's a batteries-not-included problem, so the analysis
> work required to make good use of it as a receiver is likely to be
> infeasible for smaller receivers meaning that:

Yes.  Exactly it.

> - initially only larger receivers will do it, and
> - if it works then, over time, vendors/developers will embed slow-moving
> pieces in products and/or reputation data providers will add faster moving
> pieces to their services.
> 
> This is just a diffusion process, not an exclusion of smaller players.
> Indeed, it would almost appear that you'd be happier if the big guys had
> excluded smaller players from this initiative...

Until maybe someday the results of the analysis to use ARC are somehow 
available, they have.  The use of an open standard (which I am in favor of and 
this is good), doesn't materially change that.  If I can write code to 
implement a standard, but don't have the necessary inputs to use it, it's not 
particularly of use.

> I'd also point out that we spent most of a decade (2003 - 2011) wandering in
> a highly-inclusive -all/o=-/discardable wilderness. It took the world's
> most-heavily-phished organisation working directly with one of the big guys
> in private to get any purchase on the problem, and their subsequent sharing
> of it (DMARC) to bring about progress more broadly. It would appear that
> ARC is on a similar path to improving the situation for largest unresolved
> piece of the problem (supporting forwarding). This does suggest a general
> difficulty in using a consensus-driven process to devise solutions, rather
> than merely refine/standardise/evolve them, however this does not seem like
> a reason for concern, it may simply indicate that we've gotten as far as we
> can get at present with such processes. The important test when deciding
> whether to cooperate would appear to be whether the particular solution
> unduly benefits the big guys compared to other viable solutions that are
> already known about. ! If there are none, then cooperating on ARC would
> appear to be a no-brainer.

Personally, I try to consider putting my time where either I'll benefit or I 
think the global Internet will benefit.  

> > Solving the mailing list 'problem' in a way that requires me to switch to
> > gmail (or some other large scale provider) to get my list mail delivered
> > is worse than no solution at all for me.
> 
> Obviously. This is not being proposed, see the comments about about
> vendors/developers and reputation data providers.

It's not being proposed, but I expect it'll be the effect.  

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

[Franck Martin via dmarc-discuss]

Some MTAs are known to break DKIM when doing a simple forwarding. Your
failure reports may give you enough information to know what is happening
at some IPs.

On Sat, Feb 13, 2016 at 3:34 AM, Ben Greenfield via dmarc-discuss <
dmarc-discuss@dmarc.org> wrote:

> Hey All,
>
> Sorry I didn’t not realize what the question might touch off. I have been
> following the discussion and watching my traffic and I have come up with
> this theory.
>
> Looking over my reports I see I get 100% DMARC & SPF coverage with only
> 71% DKIM coverage.
> I’m assuming the DKIM coverage loss represents traffic to list-servs
> rather then a configuration issue on my end.
>
> Is that Plausible.
>
>
> Thanks,
>
> Ben
>
> > On Feb 7, 2016, at 1:10 PM, 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
> > told, somebody else broke mailing lists; this is just how I personally
> > decided to implement a fix that seems to work well for me. YMMV.
> >
> > Regards,
> > Al Iverson
> >
> > --
> > Al Iverson - Minneapolis - (312) 275-0130
> > Simple DNS Tools since 2008: xnnd.com
> > www.spamresource.com & aliverson.com
> > ___
> > dmarc-discuss mailing list
> > dmarc-discuss@dmarc.org
> > http://www.dmarc.org/mailman/listinfo/dmarc-discuss
> >
> > NOTE: Participating in this list means you agree to the DMARC Note Well
> terms (http://www.dmarc.org/note_well.html)
>
>
> ___
> dmarc-discuss mailing list
> dmarc-discuss@dmarc.org
> http://www.dmarc.org/mailman/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

[Scott Kitterman via dmarc-discuss]

On Friday, February 12, 2016 05:11:34 AM Roland Turner via dmarc-discuss 
wrote:
> John Levine 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.
> > 
> > Yes, exactly.  Pretty much the entire value of ARC is the strong hint
> > that the gorillas plan to implement it as a workaround to DMARC issues.
> 
> I am perhaps imaging things, but my recollection is that there is not merely
> a hint that ARC is being devised and implemented for this purpose, but that
> this was the openly stated rationale.

It would be nice if we didn't design standards that only worked at a certain 
scale.  "You must be this tall to ride" worries me.  

Solving the mailing list 'problem' in a way that requires me to switch to 
gmail (or some other large scale provider) to get my list mail delivered is 
worse than no solution at all for me.

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

[Franck Martin via dmarc-discuss]

On Wed, Feb 10, 2016 at 7:06 PM, Steve Atkins via dmarc-discuss <
dmarc-discuss@dmarc.org> wrote:

>
> > On Feb 10, 2016, at 6:37 PM, Roland Turner via dmarc-discuss <
> dmarc-discuss@dmarc.org> 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 
>
>
Smells like:

From: Paypal Security secur...@paypal.com 

Not sure it is a good idea.
___
dmarc-discuss mailing list
dmarc-discuss@dmarc.org
http://www.dmarc.org/mailman/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

[Franck Martin via dmarc-discuss]

John, the critic is always easy, stop bullying please.

On Thu, Feb 11, 2016 at 1:58 PM, John Levine  wrote:

> >Smells like:
> >
> >From: Paypal Security secur...@paypal.com 
> >
> >Not sure it is a good idea.
>
> It's a terrible idea.  Too bad some ill-designed security scheme
> forces people to do stuff like that.
>
> R's,
> John
>
___
dmarc-discuss mailing list
dmarc-discuss@dmarc.org
http://www.dmarc.org/mailman/listinfo/dmarc-discuss

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

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

[John Levine via dmarc-discuss]

>Smells like:
>
>From: Paypal Security secur...@paypal.com 
>
>Not sure it is a good idea.

It's a terrible idea.  Too bad some ill-designed security scheme
forces people to do stuff like that.

R's,
John
___
dmarc-discuss mailing list
dmarc-discuss@dmarc.org
http://www.dmarc.org/mailman/listinfo/dmarc-discuss

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

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

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

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

[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

[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

[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

[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

[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 

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

[Franck Martin via dmarc-discuss]

On Mon, Feb 8, 2016 at 4:35 PM, Al Iverson via dmarc-discuss <
dmarc-discuss@dmarc.org> wrote:

> On Mon, Feb 8, 2016 at 1:51 PM, John R Levine via dmarc-discuss
>  wrote:
> >> It is even worse than I thought, you really want to stop efforts in
> >> fighting phish, by muddling the waters between real domains and fake
> ones
> >
> >
> > There's no muddling going on.  dmarc.fail is a real domain that should
> have
> > an excellent reputation since it sends no phish.
>
> I think Franck is right. It is muddying the waters by introducing a
> wholly other domain that has nothing to do with the list or the
> subscriber. Not seeing why anybody would recommend that as a best
> practice.
>
>
>
Not to mention this is also a privacy issue. Now the owner of dmarc.fail
has visibility on some traffic he/she should not see.
___
dmarc-discuss mailing list
dmarc-discuss@dmarc.org
http://www.dmarc.org/mailman/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

[John Levine via dmarc-discuss]

>Not to mention this is also a privacy issue. Now the owner of dmarc.fail
>has visibility on some traffic he/she should not see.

Oh, come on.  The owner of dmarc.fail is me, and I assign the addresses
to mail that goes through my own web server.

R's,
John
___
dmarc-discuss mailing list
dmarc-discuss@dmarc.org
http://www.dmarc.org/mailman/listinfo/dmarc-discuss

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

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 <dmarc-discuss-boun...@dmarc.org> on behalf of Scott 
Kitterman via dmarc-discuss <dmarc-discuss@dmarc.org>
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://w

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

[John R Levine via dmarc-discuss]

It is even worse than I thought, you really want to stop efforts in
fighting phish, by muddling the waters between real domains and fake ones


There's no muddling going on.  dmarc.fail is a real domain that should 
have an excellent reputation since it sends no phish.




sigh!

On Sun, Feb 7, 2016 at 1:02 PM, John R Levine  wrote:


mailing list.  For example. mail from mari...@yahoo.com turns into

mari...@yahoo.com.dmarc.fail.

Except that @yahoo.com.dmarc.fail is not a domain that exists, and will

negatively impact the email deliverability.



Why in the world would you say that?  It not only exists, it's DNSSEC
signed which is more than you can say about linkedin.com.

Forwarding email addresses in yahoo.com.dmarc.com exist for a couple of
days after someone at the corresponding yahoo.com address sends mail
through any of my mailing lists, same for any other address in a domain
with a DMARC policy.

R's,
John

; <<>> DiG 9.8.3-P1 <<>> yahoo.com.dmarc.fail mx +dnssec
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 30940
;; flags: qr rd ra ad; QUERY: 1, ANSWER: 2, AUTHORITY: 6, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags: do; udp: 4096
;; QUESTION SECTION:
;yahoo.com.dmarc.fail.  IN  MX

;; ANSWER SECTION:
yahoo.com.dmarc.fail.   3585IN  MX  20 mail1.iecc.com.
yahoo.com.dmarc.fail.   3585IN  RRSIG   MX 8 2 3600 2016040300
20160201054514 58563 dmarc.fail.
IZIPS60KsnOEFMX/gYo/3o8zzlIzfhFTrmo2IkbKMLWoWQPIAwXLZRDk
jXXmymrxYSJ1k3yUUVztCSKzDBWFu4WvYiUwpc9NbG3v7DdN1OwUkxcM
RgjmqjMxwPcQI1RFoJkgPD1V3azJDOV/f73bd4HPimVD5r6SP/s/v3gc 1s8=

;; AUTHORITY SECTION:
*.k1602._domainkey.dmarc.fail. 7185 IN  NSECdmarc.fail. TXT RRSIG NSEC
*.k1602._domainkey.dmarc.fail. 7185 IN  RRSIG   NSEC 8 4 7200
2016040300 20160201054514 58563 dmarc.fail.
Ue/IR/Gdy4DJHsEJgToONRMP9j5Skyf8hxIHCCGPTyNc+URgtJFDpilS
21MTC7zuCIt4fIKV8x428VJDzg2fZzMFQNDuMmtvs8aLMVL6TGAfKlVQ
NjbYowFrS6g5xTFpkm5SdJmNnLreymuVksVFeniO2Td2+bn2Vvr7hzfc iAw=
dmarc.fail. 1429IN  NS  sdn.iecc.com.
dmarc.fail. 1429IN  NS  osdn.iecc.com.
dmarc.fail. 1429IN  NS  light.lightlink.com.
dmarc.fail. 1429IN  RRSIG   NS 8 2 3600 2016040300
20160201054514 58563 dmarc.fail.
sZOP1+0qp3pCrk0l9VcEivHak4+v2I32jp9m6iysYTO49m6s6qadiyIy
I3O21vr4Tk5V+XoN9F/zaIctT4nvDH2mIiDN24cB2uGb05zRg809ars5
WqOOBCBkYiKJUNi95LmZ0W2VCXqVwTxEYLC4r9EFoBGEm/dloDcWVjG7 Z6A=

;; Query time: 0 msec
;; SERVER: 192.168.80.2#53(192.168.80.2)
;; WHEN: Sun Feb  7 15:57:10 2016
;; MSG SIZE  rcvd: 707





Regards,
John Levine, jo...@taugh.com, Taughannock Networks, Trumansburg NY
Please consider the environment before reading this e-mail.
___
dmarc-discuss mailing list
dmarc-discuss@dmarc.org
http://www.dmarc.org/mailman/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

[Franck Martin via dmarc-discuss]

It is even worse than I thought, you really want to stop efforts in
fighting phish, by muddling the waters between real domains and fake ones

sigh!

On Sun, Feb 7, 2016 at 1:02 PM, John R Levine  wrote:

> mailing list.  For example. mail from mari...@yahoo.com turns into
>>> mari...@yahoo.com.dmarc.fail.
>>>
>>> Except that @yahoo.com.dmarc.fail is not a domain that exists, and will
>> negatively impact the email deliverability.
>>
>
> Why in the world would you say that?  It not only exists, it's DNSSEC
> signed which is more than you can say about linkedin.com.
>
> Forwarding email addresses in yahoo.com.dmarc.com exist for a couple of
> days after someone at the corresponding yahoo.com address sends mail
> through any of my mailing lists, same for any other address in a domain
> with a DMARC policy.
>
> R's,
> John
>
> ; <<>> DiG 9.8.3-P1 <<>> yahoo.com.dmarc.fail mx +dnssec
> ;; global options: +cmd
> ;; Got answer:
> ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 30940
> ;; flags: qr rd ra ad; QUERY: 1, ANSWER: 2, AUTHORITY: 6, ADDITIONAL: 1
>
> ;; OPT PSEUDOSECTION:
> ; EDNS: version: 0, flags: do; udp: 4096
> ;; QUESTION SECTION:
> ;yahoo.com.dmarc.fail.  IN  MX
>
> ;; ANSWER SECTION:
> yahoo.com.dmarc.fail.   3585IN  MX  20 mail1.iecc.com.
> yahoo.com.dmarc.fail.   3585IN  RRSIG   MX 8 2 3600 2016040300
> 20160201054514 58563 dmarc.fail.
> IZIPS60KsnOEFMX/gYo/3o8zzlIzfhFTrmo2IkbKMLWoWQPIAwXLZRDk
> jXXmymrxYSJ1k3yUUVztCSKzDBWFu4WvYiUwpc9NbG3v7DdN1OwUkxcM
> RgjmqjMxwPcQI1RFoJkgPD1V3azJDOV/f73bd4HPimVD5r6SP/s/v3gc 1s8=
>
> ;; AUTHORITY SECTION:
> *.k1602._domainkey.dmarc.fail. 7185 IN  NSECdmarc.fail. TXT RRSIG NSEC
> *.k1602._domainkey.dmarc.fail. 7185 IN  RRSIG   NSEC 8 4 7200
> 2016040300 20160201054514 58563 dmarc.fail.
> Ue/IR/Gdy4DJHsEJgToONRMP9j5Skyf8hxIHCCGPTyNc+URgtJFDpilS
> 21MTC7zuCIt4fIKV8x428VJDzg2fZzMFQNDuMmtvs8aLMVL6TGAfKlVQ
> NjbYowFrS6g5xTFpkm5SdJmNnLreymuVksVFeniO2Td2+bn2Vvr7hzfc iAw=
> dmarc.fail. 1429IN  NS  sdn.iecc.com.
> dmarc.fail. 1429IN  NS  osdn.iecc.com.
> dmarc.fail. 1429IN  NS  light.lightlink.com.
> dmarc.fail. 1429IN  RRSIG   NS 8 2 3600 2016040300
> 20160201054514 58563 dmarc.fail.
> sZOP1+0qp3pCrk0l9VcEivHak4+v2I32jp9m6iysYTO49m6s6qadiyIy
> I3O21vr4Tk5V+XoN9F/zaIctT4nvDH2mIiDN24cB2uGb05zRg809ars5
> WqOOBCBkYiKJUNi95LmZ0W2VCXqVwTxEYLC4r9EFoBGEm/dloDcWVjG7 Z6A=
>
> ;; Query time: 0 msec
> ;; SERVER: 192.168.80.2#53(192.168.80.2)
> ;; WHEN: Sun Feb  7 15:57:10 2016
> ;; MSG SIZE  rcvd: 707
>
___
dmarc-discuss mailing list
dmarc-discuss@dmarc.org
http://www.dmarc.org/mailman/listinfo/dmarc-discuss

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

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

[Al Iverson via dmarc-discuss]

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

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


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

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

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

[Ben Greenfield via dmarc-discuss]

> On Feb 1, 2016, at 9:53 PM, Steven M Jones  wrote:
> 
>> Should one use one DKIM key for each domain or a single domain tie it to the 
>> ip addresses and the DNS text records sort out whether the domain is 
>> associated with the sending ip’s DKIM key.
> 
> I may just not be following you, but DKIM doesn't mandate or require any
> association with IP addresses. And in fact that's a good thing, because
> it allows DKIM-signed messages to be forwarded and still be verifiable
> (provided the message isn't altered).

I guess I was a little sloppy in my phrasing. I’m wondering if I’m using 
virtual hosts should I generate individual DKIM keys.

> 
> DKIM signatures include information about which domain produced/attached
> the signature, and how to retrieve the public key via DNS in order to
> verify that signature. If you look at the DKIM-Signature: header in a
> message, this information is in the selector ("s=...") and signing
> domain (in full, the Signing Domain IDentifier, or SDID - the "d=...")
> fields.
> 
> You might choose to only deploy a given signing key on a given host,
> thereby effectively creating that association. But DKIM allows you to
> use the same signing key on multiple hosts, and many people do this.

So really I should consider a DKIM key as quite transportable.


> You
> can deploy multiple keys under different selectors for one domain to one
> or more hosts. Or you might deploy keys for several different
> (sub-)domains to one or several hosts. There's a lot of flexibility if
> you need it.
> 
> Check the DKIM RFC: https://tools.ietf.org/html/rfc6376
> The DKIM Service Overview: https://tools.ietf.org/html/rfc5585
> 
> Or look for other resources on the DKIM.org site: http://dkim.org/
> 
> 
>> My question regarding mailman is that I see discussion of problems with 
>> listserv’s but so far I haven’t seen any that seem to apply to my situation.
> 
> The problems associated with mailing lists, or more generally "indirect
> mailflows," come when a message submitted to the list is forwarded out
> to the list recipients such that SPF no longer passes, and if present a
> DKIM signature no longer verifies because the message was altered in
> some way.
> 
> So if the original sending domain has published a restrictive DMARC
> policy (not "p=none"), the message would fail the DMARC check and would
> likely be quarantined or rejected - if the receiver didn't know the
> message had come through a list, and chose to allow an exception for
> that list/host.
> 
> 
>> We have an internal staff mailing list and a public mailing list. 
>> Should I look in the Maillman docs for the right configuration? 
>> Is their a consensus on what to do with listservs?
> 
> You might want to check the MailMan site, docs, or discussion forums.
> 
> But MailMan includes an option that effectively works around the
> problems with strict DMARC policies and indirect flows by altering the
> RFC5322.From: header of the outgoing message to use the mailing list's
> address. Note that not everybody likes this approach, but it does work.
> 
> If you check the "General Options" screen for the list admin interface,
> you'll see an option described as:
> 
> "Replace the From: header address with the list's posting address to
> mitigate issues stemming from the original From: domain's DMARC or
> similar policies."
> 
> I've used the "Munge From" setting in cases where list participants'
> strict DMARC policies (or those of their mailbox provider) were or would
> cause issues.
> 
> 
> One approach that would avoid this kind of workaround was announced in
> October. The Authenticated Received Chain, or ARC, would allow mailing
> lists and other intermediaries to include the email authentication
> results they observed when a message arrived, and some signatures of
> same, that the ultimate recipient might then choose to use if/when
> regular DKIM/SPF/DMARC checks fail. For more info on that head over to
> http://arc-spec.org.
> 
> Hope that helps,
> —Steve.
> 


Thank you for your answers,

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)

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

[John Levine via dmarc-discuss]

In article 

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

[Franck Martin via dmarc-discuss]

On Sun, Feb 7, 2016 at 12:22 PM, John Levine via dmarc-discuss <
dmarc-discuss@dmarc.org> wrote:

> In article 

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

[Scott Kitterman via dmarc-discuss]

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
> > told, somebody else broke mailing lists; this is just how I personally
> > decided to implement a fix that seems to work well for me. YMMV.
> > 
> > Regards,
> > Al Iverson
> > 
> > --
> > Al Iverson - Minneapolis - (312) 275-0130
> > Simple DNS Tools since 2008: xnnd.com
> > www.spamresource.com & aliverson.com
> > ___
> > dmarc-discuss mailing list
> > dmarc-discuss@dmarc.org
> > http://www.dmarc.org/mailman/listinfo/dmarc-discuss
> > 
> > NOTE: Participating in this list means you agree to the DMARC Note Well
> > terms (http://www.dmarc.org/note_well.html)

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

[Franck Martin via dmarc-discuss]

This is not the point

On Sun, Feb 7, 2016 at 11:43 AM, Scott Kitterman via dmarc-discuss <
dmarc-discuss@dmarc.org> wrote:

> 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
> > > told, somebody else broke mailing lists; this is just how I personally
> > > decided to implement a fix that seems to work well for me. YMMV.
> > >
> > > Regards,
> > > Al Iverson
> > >
> > > --
> > > Al Iverson - Minneapolis - (312) 275-0130
> > > Simple DNS Tools since 2008: xnnd.com
> > > www.spamresource.com & aliverson.com
> > > ___
> > > dmarc-discuss mailing list
> > > dmarc-discuss@dmarc.org
> > > http://www.dmarc.org/mailman/listinfo/dmarc-discuss
> > >
> > > NOTE: Participating in this list means you agree to the DMARC Note Well
> > > terms (http://www.dmarc.org/note_well.html)
>
> ___
> dmarc-discuss mailing list
> dmarc-discuss@dmarc.org
> http://www.dmarc.org/mailman/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

[John R Levine via dmarc-discuss]

mailing list.  For example. mail from mari...@yahoo.com turns into
mari...@yahoo.com.dmarc.fail.


Except that @yahoo.com.dmarc.fail is not a domain that exists, and will
negatively impact the email deliverability.


Why in the world would you say that?  It not only exists, it's DNSSEC 
signed which is more than you can say about linkedin.com.


Forwarding email addresses in yahoo.com.dmarc.com exist for a couple of 
days after someone at the corresponding yahoo.com address sends mail 
through any of my mailing lists, same for any other address in a domain 
with a DMARC policy.


R's,
John

; <<>> DiG 9.8.3-P1 <<>> yahoo.com.dmarc.fail mx +dnssec
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 30940
;; flags: qr rd ra ad; QUERY: 1, ANSWER: 2, AUTHORITY: 6, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags: do; udp: 4096
;; QUESTION SECTION:
;yahoo.com.dmarc.fail.  IN  MX

;; ANSWER SECTION:
yahoo.com.dmarc.fail.   3585IN  MX  20 mail1.iecc.com.
yahoo.com.dmarc.fail.   3585IN  RRSIG   MX 8 2 3600 2016040300 
20160201054514 58563 dmarc.fail. 
IZIPS60KsnOEFMX/gYo/3o8zzlIzfhFTrmo2IkbKMLWoWQPIAwXLZRDk 
jXXmymrxYSJ1k3yUUVztCSKzDBWFu4WvYiUwpc9NbG3v7DdN1OwUkxcM 
RgjmqjMxwPcQI1RFoJkgPD1V3azJDOV/f73bd4HPimVD5r6SP/s/v3gc 1s8=

;; AUTHORITY SECTION:
*.k1602._domainkey.dmarc.fail. 7185 IN  NSECdmarc.fail. TXT RRSIG NSEC
*.k1602._domainkey.dmarc.fail. 7185 IN  RRSIG   NSEC 8 4 7200 2016040300 
20160201054514 58563 dmarc.fail. 
Ue/IR/Gdy4DJHsEJgToONRMP9j5Skyf8hxIHCCGPTyNc+URgtJFDpilS 
21MTC7zuCIt4fIKV8x428VJDzg2fZzMFQNDuMmtvs8aLMVL6TGAfKlVQ 
NjbYowFrS6g5xTFpkm5SdJmNnLreymuVksVFeniO2Td2+bn2Vvr7hzfc iAw=
dmarc.fail. 1429IN  NS  sdn.iecc.com.
dmarc.fail. 1429IN  NS  osdn.iecc.com.
dmarc.fail. 1429IN  NS  light.lightlink.com.
dmarc.fail. 1429IN  RRSIG   NS 8 2 3600 2016040300 
20160201054514 58563 dmarc.fail. 
sZOP1+0qp3pCrk0l9VcEivHak4+v2I32jp9m6iysYTO49m6s6qadiyIy 
I3O21vr4Tk5V+XoN9F/zaIctT4nvDH2mIiDN24cB2uGb05zRg809ars5 
WqOOBCBkYiKJUNi95LmZ0W2VCXqVwTxEYLC4r9EFoBGEm/dloDcWVjG7 Z6A=

;; Query time: 0 msec
;; SERVER: 192.168.80.2#53(192.168.80.2)
;; WHEN: Sun Feb  7 15:57:10 2016
;; MSG SIZE  rcvd: 707
___
dmarc-discuss mailing list
dmarc-discuss@dmarc.org
http://www.dmarc.org/mailman/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

[Scott Kitterman via dmarc-discuss]

On Sunday, February 07, 2016 08:25:13 PM John Levine wrote:
> In article <2049568.4HsipfqAXp@kitterma-e6430> you write:
> >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.
> 
> If you're suggesting that ARC is only useful when you already trust
> the forwarding party, and if you trust the forwarding party, why do
> you need ARC, yeah, that's been pointed out before.
> 
> The best explanation I've seen was from someone at Google who said
> that they often see well behaved lists suddenly start to send spam
> when a spambot happens to send mail that fakes a subscriber's return
> address.  ARC would make it somewhat easier to tell when that happens.

OK.  Specifically in a DMARC context (this being the DMARC list), I don't see 
that it's particularly related to DMARC and solving the DMARC mailing list 
problem.  For the reasons you correctly state have been gone over before.

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

[John Levine via dmarc-discuss]

In article <2049568.4HsipfqAXp@kitterma-e6430> you write:
>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.

If you're suggesting that ARC is only useful when you already trust
the forwarding party, and if you trust the forwarding party, why do
you need ARC, yeah, that's been pointed out before.

The best explanation I've seen was from someone at Google who said
that they often see well behaved lists suddenly start to send spam
when a spambot happens to send mail that fakes a subscriber's return
address.  ARC would make it somewhat easier to tell when that happens.

R's,
John
___
dmarc-discuss mailing list
dmarc-discuss@dmarc.org
http://www.dmarc.org/mailman/listinfo/dmarc-discuss

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

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

[Franck Martin via dmarc-discuss]

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
> told, somebody else broke mailing lists; this is just how I personally
> decided to implement a fix that seems to work well for me. YMMV.
>
> Regards,
> Al Iverson
>
> --
> Al Iverson - Minneapolis - (312) 275-0130
> Simple DNS Tools since 2008: xnnd.com
> www.spamresource.com & aliverson.com
> ___
> dmarc-discuss mailing list
> dmarc-discuss@dmarc.org
> http://www.dmarc.org/mailman/listinfo/dmarc-discuss
>
> NOTE: Participating in this list means you agree to the DMARC Note Well
> terms (http://www.dmarc.org/note_well.html)
>
___
dmarc-discuss mailing list
dmarc-discuss@dmarc.org
http://www.dmarc.org/mailman/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

[Steven M Jones via dmarc-discuss]

On 01/23/2016 05:08, Ben Greenfield via dmarc-discuss wrote:
> My name is Ben Greenfield and I have been running a couple of smalltime mail 
> servers (fewer then 200 messages a day) not accounting for an occasional 
> blast from a 1,500 person listserv.

Welcome Ben, and hopefully you got a response off-list (or that I missed
it).


> Should one use one DKIM key for each domain or a single domain tie it to the 
> ip addresses and the DNS text records sort out whether the domain is 
> associated with the sending ip’s DKIM key.

I may just not be following you, but DKIM doesn't mandate or require any
association with IP addresses. And in fact that's a good thing, because
it allows DKIM-signed messages to be forwarded and still be verifiable
(provided the message isn't altered).

DKIM signatures include information about which domain produced/attached
the signature, and how to retrieve the public key via DNS in order to
verify that signature. If you look at the DKIM-Signature: header in a
message, this information is in the selector ("s=...") and signing
domain (in full, the Signing Domain IDentifier, or SDID - the "d=...")
fields.

You might choose to only deploy a given signing key on a given host,
thereby effectively creating that association. But DKIM allows you to
use the same signing key on multiple hosts, and many people do this. You
can deploy multiple keys under different selectors for one domain to one
or more hosts. Or you might deploy keys for several different
(sub-)domains to one or several hosts. There's a lot of flexibility if
you need it.

Check the DKIM RFC: https://tools.ietf.org/html/rfc6376
The DKIM Service Overview: https://tools.ietf.org/html/rfc5585

Or look for other resources on the DKIM.org site: http://dkim.org/


> My question regarding mailman is that I see discussion of problems with 
> listserv’s but so far I haven’t seen any that seem to apply to my situation.

The problems associated with mailing lists, or more generally "indirect
mailflows," come when a message submitted to the list is forwarded out
to the list recipients such that SPF no longer passes, and if present a
DKIM signature no longer verifies because the message was altered in
some way.

So if the original sending domain has published a restrictive DMARC
policy (not "p=none"), the message would fail the DMARC check and would
likely be quarantined or rejected - if the receiver didn't know the
message had come through a list, and chose to allow an exception for
that list/host.


> We have an internal staff mailing list and a public mailing list. 
> Should I look in the Maillman docs for the right configuration? 
> Is their a consensus on what to do with listservs?

You might want to check the MailMan site, docs, or discussion forums.

But MailMan includes an option that effectively works around the
problems with strict DMARC policies and indirect flows by altering the
RFC5322.From: header of the outgoing message to use the mailing list's
address. Note that not everybody likes this approach, but it does work.

If you check the "General Options" screen for the list admin interface,
you'll see an option described as:

"Replace the From: header address with the list's posting address to
mitigate issues stemming from the original From: domain's DMARC or
similar policies."

I've used the "Munge From" setting in cases where list participants'
strict DMARC policies (or those of their mailbox provider) were or would
cause issues.


One approach that would avoid this kind of workaround was announced in
October. The Authenticated Received Chain, or ARC, would allow mailing
lists and other intermediaries to include the email authentication
results they observed when a message arrived, and some signatures of
same, that the ultimate recipient might then choose to use if/when
regular DKIM/SPF/DMARC checks fail. For more info on that head over to
http://arc-spec.org.

Hope that helps,
--Steve.

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

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

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

[Steven M Jones via dmarc-discuss]

On 02/01/2016 18:53, Steven M Jones via dmarc-discuss wrote:
>
>> My question regarding mailman is that I see discussion of problems with 
>> listserv’s but so far I haven’t seen any that seem to apply to my situation.
> The problems associated with mailing lists, or more generally "indirect
> mailflows," ...

Oops - I meant to include a reference to the IETF DMARC Working Group's
draft that documents issues with (certain DMARC policies and) indirect
mailflows:

https://datatracker.ietf.org/doc/draft-ietf-dmarc-interoperability/

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

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

[Ben Greenfield via dmarc-discuss]

Hey All,

My name is Ben Greenfield and I have been running a couple of smalltime mail 
servers (fewer then 200 messages a day) not accounting for an occasional blast 
from a 1,500 person listserv.
All the machines our hosted onsite.

I have been running SPF, DKIM, and DMARC for about a week and one domain came 
up clean in my DMARC reports and the other sounded just like Denis’s post.
I got my first DMARC report yesterday and it was very discomforting and I 
immediately went 2 p=quarantine and this morning I got more scary reports and 
came across Denis’s request for advice and went to p=reject.

I feel this is safe because I personally know all the users of the mail servers 
and have no doubt that all the threat activity was fraudulent. The one subtle 
bit is what happens to the forwarder mail. I assume if the DMARC stays in tact 
everything is fine.

My question regarding virtual mail servers. 

Should one use one DKIM key for each domain or a single domain tie it to the ip 
addresses and the DNS text records sort out whether the domain is associated 
with the sending ip’s DKIM key.

My question regarding mailman is that I see discussion of problems with 
listserv’s but so far I haven’t seen any that seem to apply to my situation.

We have an internal staff mailing list and a public mailing list. 
Should I look in the Maillman docs for the right configuration? 
Is their a consensus on what to do with listservs?

Any other comments welcome as well since I’m new to this. 

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)