Gregory's Server@lauren Sure. I'd agree to that too. The bigger problem is that this flaw can severely damage the reputation of small(er) servers, getting them added to blacklists of the Big Mail oligopoly. That's why we mail admins of small servers are (forced to) always working hard to mitigate any possibility of that happening. But mitigations have been published by postfix, exim, sendmail. What bothers me is that this could have all been solved months ago, if done in a different way :(
|
4 comments
 @jwildeboer I don't see how it will make the blacklists any larger. Big Mail (to the extent they are affected) will fix it on their inbound, and the blacklists aren't likely to add servers to the lists that still can be verified via IP-based means like SPF. It's not like this can't be figured out. I haven't seen any sendmail mitigation, by the way, except something that might apply to the very latest version that doesn't even run widely. @jwildeboer Anyway, anything smaller servers can do is negligible. They can't do anything outbound to fix this. And at a small scale inbound won't matter much either in the scheme of things compared with "Big Mail".  @lauren Better safe than sorry, IMHO. I have hardened my mail server against this and I see many other admins do the same. I also see the developers working hard to get fixes done and out. On the day before Christmas. Because SEC consult decided to only share their findings with "Big Mail" and then hoped for 6 months that others (CERT/CC) would inform other affected projects so they could focus on their presentation for 37C3. :( |
@lauren And (at least according to some early checks) this flaw isn't limited to DMARC spoofing. It could potentially be used for phishing and other abusive attacks too. This is why sendmail, exim and postfix (and more, I guess) have decided to treat this with high priority.