On 10-01-13 22:55, Franck Martin wrote: > What I (we?) don't want is that DMARC affects the reputation of the email > as spammers will publish a DMARC record if it lowers their spamassassin > score.
My idea was more along the lines: - add some informational rules with near-zero scores that tell the recipient about Dmarc policy existance and contents (see: DKIM_SIGNED) - add some penalty rules when policy evaluation fails, or alignment fails. While it does not improve deliverablity for poor-formatted senders (both phish and legit), it would create a direct positive experience for recipients: block more phish mail. > > Also I think the RFC specifies that aggregate reports are an integral part > of DMARC. You can't develop one without the other. Noted. > > The opendmarc milter/proxy way seems the way to go, spamassassin is > installed this way on linux boxes, I don't see why it would not be as easy > to install opendmarc. I used Spamassassin just as an example, but let's stay on that route. - It has already a huge install base, adding a plugin to something that already exists is easier than integrating a new piece of software in your mailstack. - It has lots of ways to integrate other than a milter api. - Not everyone runs a milter-capable MTA. > > On 1/10/13 1:04 PM, "Tom Hendrikx" <[email protected]> wrote: > >> Hi, >> >> I was pondering on using DMARC in a passive way: implementing a plugin >> for spamassassin (or similar) that would only score/reject/quarantine >> based on DMARC alignment and policy, and not handle all the complex >> DMARC stuff (mainly database setup, ruf/rua sending). >> >> This would lower the implementation doorstep to test DMARC effectiveness >> for interested receivers: such an implementation would need nothing but >> access to DNS, making system administration (both setup and maintenance) >> a breeze. >> >> I do see the risk that, while intended for evaluation, such a setup >> would lower the incentive to switch to a full-blown setup such as the >> existing milter solution later on. The specification document has some >> notices pointing out the importance of the feedback loop (and I >> understand and support them), which are blatantly ignored by the above. >> But I still see an implementation benefit for small receiving sites, >> whose reports would be less significant to senders (IMHO), as existing >> large sites will also send them reports. >> >> My personal point of view: getting a DMARC sender (monitor) policy >> running was quite easy for my personal domain, but I did not have time >> to implement the receiving side yet, thus I don't get any 'benefits' >> that prove to me (and f.i. my $workjob manager) that implementing DMARC >> is actually useful. A lower doorstep would be nice. >> >> Note that I don't intend to cripple the feedback concept or DMARC in >> general, but just interested in any opinions on this. >> >> Kind regards, >> Tom >> _______________________________________________ >> dmarc-discuss mailing list >> [email protected] >> http://www.dmarc.org/mailman/listinfo/dmarc-discuss >> >> NOTE: Participating in this list means you agree to the DMARC Note Well >> terms (http://www.dmarc.org/note_well.html) > > > _______________________________________________ > dmarc-discuss mailing list > [email protected] > http://www.dmarc.org/mailman/listinfo/dmarc-discuss > > NOTE: Participating in this list means you agree to the DMARC Note Well terms > (http://www.dmarc.org/note_well.html) > _______________________________________________ dmarc-discuss mailing list [email protected] http://www.dmarc.org/mailman/listinfo/dmarc-discuss NOTE: Participating in this list means you agree to the DMARC Note Well terms (http://www.dmarc.org/note_well.html)
