On Thursday, June 19, 2014 17:40:43 Alexander Wirt wrote: > On Thu, 19 Jun 2014, Marco d'Itri wrote: > > On Jun 19, Marco d'Itri <m...@linux.it> wrote: > > > I propose that: > > > - we immediately start rejecting mails to our lists sent from domains > > > > > > with a p=reject policy to prevent unsubscribing innocent third parties > > > > This requires installing opendmarc and its dependencies and verifying > > the results in smartlist. > > I would implement that at smtp time with a postfix policyd.
You can't, not completely anyway. The lookup key for the DNS record is the body From. The sender exposed in the Postfix policy interface is the envelope From (Mail From). In most cases for a submission to a list, they will be the same, but it's not a 100% solution. It should not be too hard to us a milter to do this. I doesn't need all the functionality of opendmarc, it just has to pull out the body from, do a DNS lookup and then then reject if there is a p=reject DMARC record. > > > - we start discussing a long term solution which will allow posts from > > > > > > p=reject domains as well > > > > The possible solutions are: > > > > a) keep rejecting mail from these domains > > "Soon" it will apply to too many users, so I do not believe that this > > can be a long term approach. > > in my eyes this is the only solution, that we have in the moment. I am not > happy with it, but DMARC is total broken by design and there are no > satisfying solutions. > > > b) rewrite the From headers of messages from these domains > > The least annoying solution could be to rewrite p=reject domains with > > something like s/$/.rewritten-by.lists.debian.org/ (and maybe add the > > original domain to the Reply-To header). > > We could even setup a MX for *.rewritten-by.lists.debian.org and reject > > mail sent to it with instructions about how to reconstruct the original > > header. > > This can be intrusive and annoying for readers, but if the impact on > > the usability for the readers is considered acceptable then it is still > > better than just rejecting the messages. > > I have some experience with such rewrites from other lists (they all > reverted such settings) and they are annoying as hell. So I would object > against implementing such a scheme. > > > c) implement a permanent and elegant solution like > > http://wiki.asrg.sp.am/wiki/Mitigating_DMARC_damage_to_third_party_mail#R > > elay_one_copy_through_author_domain_server This solves the problem for all > > sides, but requires writing some > > non-trivial code and forces us to store the SMTPAUTH credentials of the > > submitters, which would be a big security risk for them. > > (A possible alternative to phishing the submitters' credentials would be > > to use some not yet specified OAUTH authentication scheme.) > > to be honest I can't see what is elegant with collecting SMTP Auth > credentials. I don't want to collect such credentials (and users should not > encouraged in handing out credentials to third partys). > > The whole DMARC thing is a nightmare for every mailinglist. > > unsatisfied I've been peripherally involved in DMARC development (which is why I packaged opendmarc). Up until Yahoo and AOL went insane, the idea was that DMARC was mostly for corporate transactional mail and the mailing list issue wouldn't come up. Scott K
signature.asc
Description: This is a digitally signed message part.
