On Fri, Jan 15, 2016 at 07:01:30PM +1100, Russell Coker wrote:
On Fri, 15 Jan 2016 04:54:22 PM Craig Sanders via luv-main wrote:
DKIM is an ill-conceived abomination. It actually cares about the *headers* in a message rather than the **envelope*. To an MTA, headers are irrelevant, they're just comments....what matters is the envelope sender address and the envelope recipient address.
And worse, DKIM cares about the From: header rather than the Sender: header.
It cares about what the user sees. The purpose of DKIM is not to ensure that only Paypal can have an envelope sender saying paypal.com, it's purpose is to ensure that only Paypal can have a From: field with paypal.com.
and that's the problem. after the message has been sent by the originating MUA or MTA (where To, From, CC, Bcc are used to construct the envelope sender & recipient), headers are merely comments. To treat them as anything different is just plain wrong. and restricting @paypal.com From: headers to just paypal-owned sender host is pointless anyway - phishers register every possible variant and look-alike of paypal.com and spam with that. often they don't even bother using a domain that looks or sounds even remotely like paypal.com - and it makes no difference. their typical victims are too stupid to notice or care - and it's not just a matter of ignorance, it's stupidity. phishing on the net has been around for at least a decade and a half now, it's not possible for an internet user over the age of about 5 to not know about it and realise they should be wary of unsolicitied emails asking them to click on a link or login to reactivate their account or check out this amazing multi-million dollar business deal or charity gift etc.
This is just broken in every possible way.
If only people who developed SMTP in the early days had thought of spam and phishing.
spam is horrible, something must be done. DMARC is something, so we must do DMARC. btw, like SPF, DKIM and DMARC are not anti-spam tools. they're anti-forgery tools. there's a huge difference. in the early days of SPF many people complained that it didn't do much to block spam (because spammers could forge domains without SPF records or just register and add SPF records to their own domains), and just plain refused to hear it when told that spam-blocking was not SPF's purpose. and if the developers of SMTP had thought of spam etc, and designed SMTP to have built-in authentication, it would have seriously damaged the open nature of the internet as we know it today. the fact that the net was built open and not locked down was a major contributor to its success.
unfortunately, you stil haven't impleemnted the minimum-damage option that only munges posts that are sent by users from domains that implement DKIM (like google or yahoo), and leaves other mail alone.
I don't like the idea of having different handling methods for different messages. We have already had one user complain about this even though we aren't doing it!
Tony's complaints have nothing to do with the list. when he's CC-ed on list mail, sometimes he gets the message from the list first, and sometimes he gets the directly CC-ed copy first. The list has nothing to do with that, and can not affect it in the slightest. it's not a problem you can solve or do anything about, so please don't use it as an excuse to DMARC-mangle every post.
it's not like anyone ever posts from those domains to our lists anyway.
We have Wen, Joel, Tony, Tim, Trent and others posting from Gmail. We have Lev, me, and others DKIM signing their own mail.
which is one of the more annoying things about this issue - the configuration messes things up for active participants on the list, and it doesn't even provide any benefit to the lurkers who never say or contribute anything.
Apart from the ones who receive mail viw Gmail, the ones who complained about my mail going to their spam folders which started me working on this.
if mailman is breaking DKIM-signed message then that needs to be fixed. mangling headers is a crappy workaround hack, not a fix.
But list traffic is significantly greater than usual at the moment.
a lot of that is this thread complaining about DMARC.
Message forgery is a solved problem. SPF works. DKIM is a) overkill and b) unnecesary.
SPF doesn't stop forged headers unless you use DMARC.
headers are irrelevant. you can't and shouldn't trust From: headers any more than you can trust any Received: header before the ones your own server adds.
The mail servers that people use to send mail to this list are also used by people who want to send mail to Facebook. Even if every single LUV member avoided ever using Facebook then we would still be affected by what they want.
as i said, solve the right (actual!) problem. if mailman's handling of DKIM-signed messages is broken then THAT is the problem that needs to be fixed. craig -- craig sanders <cas@taz.net.au>