-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 7/10/12 3:07 AM, [email protected] wrote: > On 7/8/12 9:08 PM, Murray Kucherawy wrote: >> On 7/6/12 7:27 PM, "[email protected]" >> <[email protected]> wrote: >> >>>> Given that: >>>> >>>> * Whitelisting mailing lists is really the only way to get >>>> DMARC to work with messages forwarded by lists. >>> >>> I don¹t agree with the premise that this is something about >>> which we need to be concerned on this project. Who gets >>> phished via mailing lists? >>> >>> #Chris's reply # # I want to put this to rest as much as you >>> do. What is the expected behavior # for lists that are >>> established versus ones that are new and unlisted to all # >>> receivers. This is how a spammer could pose as a list and I >>> see it as relevant . # >> >> How would a receiver distinguish between an established list >> versus one that is new versus one that is unlisted? > > > AFAIK, the mechanics of identifying and whitelisting mailing lists > is up to each ADMD. One could simply aggregate the list in a local > CSV file, or a more preferable option is that a RBL -like DNS > server issue TXT records for each domain, letting us know if it is > a mailing list.
Another alternative is to have the sender publish their desired mailing-list exceptions using the ATPS hash scheme with its presence signaled in the DMARC policy rather than as altered DKIM signatures. When the sender detects a problem, they would be able to revoke the exception granted. The sender's exposure to third-party services would be completely under their control, unlike any dependence upon each admin composing their own exception lists. Since this scheme directly benefits the sender, the sender indicating their desired exceptions would represent a small effort on their part. If SPAMHAUS were to create an ATPS zone for mailing-lists, the sender could endorse the use of this list with a CNAME reference rather than generating their own list. > This mailinglist RBL could be an extension to an existing > SPAMHAUS, or may be dedicated to this purpose. > > The TXT response could also list information such as "date added" > so that clients can assign an appropriate amount of trust to that > assertion. (e.g. Trust the assertion that a given IP is a mailing > list or a potential new spammer) > > I think it would be beneficial to cross check the information in > this mailing list IP database against what is in the whitelist DB. > The outliers of each repository will enhance or diminish the trust > given to an IP. > >> What would a spammer posing as a list gain him or her? > > If a spammer were to become trusted via the whitelisting process > previously mentioned (or any alternative), then that would be a > risk to the goal that DMARC is trying to solve. In other words it > would permit spoofing of the FROM address via the exemption > process. > > Therefore, DMARC is only as robust as the exception process > created for handling mailing lists. Which is why there should be a way for the sender to both create the exceptions and respond to any issues that may occur. Regards, Douglas Otis -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.18 (Darwin) Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQEcBAEBAgAGBQJP/FMMAAoJEHXVwboCjGt0Qq8IAK+GHAZ+cg6ty8Qua2kqzB3n HwDk//y9AXEAJukyLHRzq9kB0CipxtEJkhE17gpDutNZFQdBBo959ZG6xDwrVBHC dvVZwHorgd4MWwMV9QyLnRAcxMrh7nfmcN9ImiTMr53++lTGAcOAoFQTy6TZpMyK PKgZ7rGb4JqYc2+S1fbYhX/XNz9bWrexwzOutN+rLL81R7COWZdNvslYR1v7RdAn aj2w2ns3dP9OP/i83Yxjabhn820eCj+PEwS7zPn070yw7cg2g8PCgrFMahmxbyb/ wF9eAO0DXvWfxoSeO+MaOTNZmNQDDN6WID3KQKbRM33y6ler7Jxk2rqQNOFVReY= =nNmb -----END PGP SIGNATURE----- _______________________________________________ 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)
