On 5/25/14, 11:48 AM, Mark Rousell wrote: > What do you think of Yahoo Groups' From munging style and their > X-Original-From header? > > Here is an example: > > X-Original-From: Mark Rousell <ma...@signal100.com> > From: "Mark Rousell ma...@signal100.com [some-mail-list]" > <some-mail-l...@yahoogroups.com> > > > I feel this is one of the better combinations of munging and new > headers. All the information is there (and is very clear) and the > X-Original-From header could (in due course) be recognised by mail > clients and mailing list archive software. > > I realise that this falls foul of > http://www.dmarc.org/supplemental/mailman-project-mlm-dmarc-reqs.html > and yet it does seem to offer many benefits, especially the > X-Original-From header and the promise it holds for automated recognition. > > It is also possible to add X-Original-From to the .INVALID/.REMOVEME > munging that some prefer too: > > X-Original-From: Mark Rousell <ma...@p-reject-domain.com> > From: "Mark Rousell [via some-mail-list]" > <ma...@p-reject-domain.com.REMOVEME> > > > > Any thoughts? > My view is that any attempt to have the Mail User Agent show a message that went through a mailing list as if it originated from the original poster (and only from that poster) is doomed, because the whole point of DMARC, is that domains that that are using DMARC are indicating that email that appears to be from their domain is only supposed to get to you from that domain, and others aren't supposed to be able to masquerade as it. If mailing list could do it, so could phishers. And if this became somewhat common, DMARC, to achieve its goal of confirming sender identity would need to add checking that.
The only possible option for that would be wrapping, where the wrapped message was EXACTLY as sent (thus no content filtering, and all additions are added to the wrapper, not the original message). The problem we are seeing is that we have domains that don't really need that restriction are using it, and the world is needing to figure out how to make this work. The real solution, in my opinion, would be a standard that deals with how MUA display the senders of messages, and a system similar to https certificates where domains (or email addresses) that really need verification could get a certificate and be able to have their addresses displayed a "verified", email pretending to be from them but not properly signed could be rejected or marked suspicious, but most personal mail would just be unverified. It should make it clear that any ESP that uses this has an obligation to let is users understand the rules, and that it users are not allowed to let 3rd parties (like mailing list or other 3rd party mailers) send on their behalf (unless the standard allows a given email address to provide a cert to a 3rd party it indicate they are an authorized remailer for them). This should deal with the phish problem, at least once people are taught to look for the verified icon from "important" sources. -- Richard Damon ------------------------------------------------------ Mailman-Users mailing list Mailman-Users@python.org https://mail.python.org/mailman/listinfo/mailman-users Mailman FAQ: http://wiki.list.org/x/AgA3 Security Policy: http://wiki.list.org/x/QIA9 Searchable Archives: http://www.mail-archive.com/mailman-users%40python.org/ Unsubscribe: https://mail.python.org/mailman/options/mailman-users/archive%40jab.org
