> 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
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
(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
> 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
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
>>
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
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
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
> >>
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
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
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
>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
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
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
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
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,
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,
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
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,
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
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
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
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
>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.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
>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
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
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
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
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:
> 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
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
>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
t
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
no
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,
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
>>>
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
> 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
In article
On Sun, Feb 7, 2016 at 12:22 PM, John Levine via dmarc-discuss <
dmarc-discuss@dmarc.org> wrote:
> In article
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
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
>
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
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
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
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
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
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
>
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
50 matches
Mail list logo