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? > > What would a spammer posing as a list gain him or her?
Dear Murray, Resolvable new domains emitted by malware are created at a rate of about 10 to 300 every second based upon requests from our customers. It is difficult to know whether a new domain represents the next big thing, or that frequently seeing a new domain should be given greater credibility. It is disappointing the ATPS specification requires modification to DKIM signatures applying this extension. This provision defeats any opportunistic approach to mailing lists under sender control. A small change in DMARC and ATPS could offer a workable solution. It would also permit new third-party service domains a means to rapidly gain credibility. While SPF may reduce the number of spoofed bounces, this spamming technique is largely unrelated to the phishing problem. SPF also is unable to deal with UTF-8 email addresses, and unlike DKIM and EHLO parameters, is not required to be conveyed as A-label values. Perhaps DMARC should also consider SPF validation of the EHLO as an acceptable alternative. For user populations heavily dependent upon understanding the source of a message in their own language, they will remain exposed when the domain displayed in their native language is never checked to ensure it is symmetrically convertible with the domain used to obtain validation records. Another requirement that could be added to DMARC. 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)
