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