On 7/10/12 10:14 AM, Murray Kucherawy wrote: > On 7/10/12 3:07 AM, "[email protected]" > <[email protected]> wrote: >>> 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. >> >> 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. > > I think this is a pretty enormous effort for little gain. For one thing, > different mailing lists operate in different ways, which means there isn't > a single mechanism that can positively identify a message as having > arrived through a list. That means identifying such traffic falls to the > realm of heuristics, and I don't believe an authentication protocol (or a > policy protocol based om authentication) should be predicated even in part > on a heuristic. Moreover, once the heuristics are either published or > determined subversively, they can be exploited.
Critical security factors are likely whether lists-- 1) modifies messages in a recognizable fashion. Such as adding a tag to the subject line, or a special header for folder placement. 2) verifies all list subscriptions. While it would be unreasonable to expect EVERY receiving administrator will determine which mailing-lists might be safely used by both their customers and those of any DMARC organizational domain, it would not be unreasonable to supplant the signaling mechanism specified in Section 4.2 of RFC6541 with a DMARC policy field. DMARC policy requests might be ignored when providers are expected to make exceptions for accommodating mailing-lists. They can not afford customer complaints nor potential liabilities. Damned if they do, and damned if they don't. The original draft that was used as a starting point for the ATPS draft did not require changes to DKIM signatures to signal the existence of this exception mechanism. DMARC could replace or override a need for a DKIM/ATPS specific signalling parameters within the signature. > And I don't believe this is an interesting use case. Phishing via lists > simply doesn't happen today. Certainly it could, but a phish sent to a > list is far more likely to be detected than one that's more targeted. > Wouldn't you agree that a BofA or PayPal phish sent to a list would draw > some attention? "I got this email from PayPal, but it has the > dmarc-discuss footer on itŠ weirdŠ" for example. While BofA or Paypal might be expected to know which mailing-lists their users are exchanging emails, it is not reasonable to expect everyone else to know this or which lists have mechanisms that guard against exploitation. Allow the sender to properly deal with this issue instead. > Since this topic is especially persistent, however, perhaps someone needs > to construct an experiment to show that it's viable and doesn't weaken the > proposed mechanism. That is, if you were to build such an experiment and > stand it up to scrutiny, I shouldn't be able to successfully attack it > unless the effort I expend makes doing so not worth my while. Prior efforts that ignored exception issues failed at ensuring the application of desired reject policies, especially when it is much cheaper for providers to ignore such requests in most cases. It is not reasonable to expect potential victims will know a specific sub-domain was intended for transactional messages, nor is it practical to expect senders to use unrecognized domains for non-transactional exchanges. >>> 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. > > Šor the absence of such a process. This should not be an issue since most of the work has already been done. Once a reputation provider has published Geo-centric mailing-lists having the necessary properties, then any DMARC domain would have the option of carving out their own list of exceptions, or simply endorsing that of the specific list defined by others by using a DNAME record or sub-domain delegation. Regards, Douglas Otis _______________________________________________ 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)
