On 04/07/2014 10:06 PM, Sabahattin Gucukoglu wrote: > On 8 Apr 2014, at 05:21, John R Levine <johnl@xxxxxxxxx> wrote: >> Mailing list apps can't "implement DMARC" other than by getting rid of every feature that makes lists more functional than simple forwarders. Given that we haven't done so for any of the previous FUSSPs that didn't contemplate mailing lists, because those features are useful to our users, it seems unlikely we'll do so now.
> Well, Mailman 2.1.16 has the FROM_IS_LIST feature that "Fixes" the problem > by putting the list address in the From: field. That seems to work, except > that you lose information (the sender's address) if the list wants to operate a > policy of "Reply goes to list". You can then assure that DKIM signatures are > valid and set up SPF, etc. This also has the effect of letting you operate > through the various cloud email platforms that try to validate sender > addresses.
I haven't seen this suggestion anywhere yet, although I don't follow DMARC development, but here goes ...
Building on the FROM_IS_LIST idea, rather than having the From be rewritten to simply "list@xxxxxxxxxxx" why not establish a convention (dare I say "standard?") to encode the real from address and list to the left of the @ sign? The rub with DMARC/SPF/DKIM is the domain itself, not the whole address.
No, the rub with DMARC in this case is the choice of a p=reject policy by a site that doesn't meet the requirements for its use.
Something like user.name-at-realsenderdomain.tld%list@xxxxxxxxxxx would work. I'm sure others could come up with better suggestions. In this way the identity of the sender is preserved, and the sending domain of the message satisfies the anti-spam tools.
The From: identity is NOT preserved. There isn't an user agent in the world that would know how to deal with this. So when people reply, their message bounces. Of course there are other tricks you can play, such as making an address that actually works. But while this trick works for things like SRS, in the case of a user-visible address, it makes a mess.
MUAs could then be adapted to decode the addresses in this form and show a "real" fake From field.
Uh huh. Even assuming you could get some traction on this with user agents - a type of software collectively notorious for being slow to adapt, implement, and update pretty much everything, you then have to get this deployed quickly to do any good.
Given that tools like DMARC more or less work for everything but mailing lists (I'm being generous here in the interests of re-framing the discussion into solutions instead of griping),
You're not being generous, you're being inaccurate. And even if this was accurate, you don't call for a change to every MLM and every UA in the world to address a completely inappropriate policy choice.
and given that mailing lists constitute a tiny percentage of overall e-mail traffic, I think that the solutions to this problem are going to lie with the mailing list software vendors. I think the above would work, but I'm not an expert in this area so feel free to tell me why I'm wrong.
Riiight. Penalize longstanding practice on the basis of traffic percentages. By that measure, spam wins. Ned