[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Fri, 17 Jul 2015 09:35:22 +0200
From: Florian Weimer <fw@...eb.enyo.de>
To: oss-security@...ts.openwall.com
Subject: Re: Re: ezmlm warning
* Reed Loden:
> You can complain all your want, but it's not going away. It cuts down on
> spam and spoofing mails too much.
I have never seen research showing that header contents matters for
mail spoofing. When sending mail which misrepresents its source, you
can just use a different domain. Then you need to look at the content
to figure out that it pretends to come from another source which
doesn't match the sender address. This is quite difficult. Before,
you just had a message with a paypal.com sender address which came
from some random dial-up/consumer IP address range, so it was easier
to see that it was not legitimate.
So DMARC actually makes regular spam filtering more difficult.
The reason operators want DMARC is that the large mail providers offer
services to opt out of spam detection completely. There is
considerably fear that other spammers could spoof those acceptable
spammers, perhaps by be resorting to such drastic measures as
BGP-based address space hijacking.
> DMARC isn't some rogue thing that just a
> few people are doing. It's all been codified as RFC 7489, and lots of mail
> providers have implemented it.
Just because there is an RFC doesn't mean it's a good idea.
> improved about it (the DMARC WG in the IETF is very busy --
> https://tools.ietf.org/html/draft-ietf-dmarc-interoperability-04 for their
> latest work on this), but ignoring DMARC is just putting your head in the
> sand.
I ignore Windows and Android, too, thank you very much.
> Best to deal with the annoying workarounds for now until the next
> evolution can be spec'd out and implemented. Otherwise, you risk losing
> important e-mail (like joyful oss-security@ mails ;-]).
Well, I don't, because as a recipient, I do not implement DMARC, and
if I would, I wouldn't reject mail at the SMTP level, but accept it
and mark it as failing DMARC validation (which is, in fact, prohibited
by RFC 7489, which is against the usual IETF practice of not
specifying operator policy in protocol specifications).
But really, there is nothing inherently wrong about such checks. It's
just poor mail service to do it unconditionally, without configuration
options for senders and recipients, and at the SMTP level. (If I'm
not mistaken, the DMARC settings are per-domain, but the sender mail
service could could still generate special DKIM headers for individual
users and recipients which are known mailing lists).
To get back on topic (at least slightly), aggressive anti-spam filters
risk that you lose import bug security bug reports. Especially for
issues affecting multiple vendors, reporters or coordinators will not
debug your mail setup for you.
> DMARC is just one aspect of that. For example, would you also request
>> that Openwall will never deploy IPv6 because Gmail rejects mail sent
>> over IPv6?
> [citation needed], considering I've sent mail over IPv6 and received it
> just fine on Gmail (Google Apps, specifically).
> https://support.google.com/mail/answer/81126?hl=en#authentication even
> mentions IPv6 is supported but just has a few extra caveats that must be
> followed.
There are regular complaints on mailop and IPv6 operator lists from
people who seem to follow all of that and can get mail into Gmail just
fine over IPv4, but keep getting obscure failures over IPv6. It's
probably a bug somewhere in the Google infrastructure (something like
truncation of an IPv4 address to the first or last 32-bit) and not an
anti-spam feature, but it's still annoying that Google can't fix that.
I don't think we will reach any agreement, so it's probably best to
stop here.
Powered by blists - more mailing lists
Please check out the
Open Source Software Security Wiki, which is counterpart to this
mailing list.
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
