On 6/4/14, 11:39 AM, Stephen J. Turnbull wrote: > Richard Damon writes: > > > There are some domains (like banks but NOT Yahoo and AOL) whose email is > > important to verify identity of sender, who should have some form of > > certificate that shows they have been verified by a trusted 3rd party > > (like Https certs). The 3rd party verification keeps phishers from using > > minor misspellings to fake these domains. > > This is what some banks do, already (poor man's version). They send > you mail, you click on a link that takes you to the bank's secure site > which authenticates itself to you (usually via some secret you have > chosen for your account, as well as verifying the site via X.500 > certificate over HTTPS). Having confirmed it is your bank's site, you > log in. Hopefully most don't put a real link, but just instructions to go to the web site (with maybe the domain which is the name of the bank). Training people to click on links here is EXACTLY the wrong thing to do here, that is the foothold that the phisher wants. The key to this proposal is that something shows in an obvious manner in the mail client to say that this email has a verified sender. If the certificates have some cost, and the issuers are held accountable for having verifiable id of the sender before issuing the certificate, you remove the a lot of the things that allow phish to work. > > > For other domains, perhaps an SPF like method on a per mailbox basis > > (this could be used by Yahoo and the like). A person joins a mailing > > list, the list send a request to a mailbox indicated to get added as an > > authorized sender, (which then somehow verifies with the user). Receiver > > gets an email from an unspecified source, mark it as suspicious or block > > it totally. This would impact programs like mailman, as if the user > > domain uses such a protection, another step needs to be added to the > > subscription process to get the user authorized to send to the > > list. > > If I understand you correctly, we actually already have the mechanics > for this in place. Most sites like Yahoo! allow you to whitelist a > sender. This could be extended to allow whitelisting based on the RFC > 2369 List-Post field (simple to implement but requires subscriber > action if the List-Post address changes) or the RFC 2919 List-Id field > (complicated because it doesn't correspond directly to any domain, > you'd need some kind of DNS support which would be a bad idea to > special case lists). > > Then just DKIM sign, and have the destination check for List-Post (not > from) identity alignment. Not as much trouble as you suggest. > > Murray, is there something here? > This isn't anything like a whitelist, but more like SPF, but for the email address, not the whole domain (and keyed to the From instead of the Sender). This way Yahoo could setup a default setting of just being able to come from yahoo servers, but when a user signs up for a mailing list, THAT address (and just that addresses) adds as an authorized sending domain, the domain for the mailing list. The receiving mail system can then check that the email came from a valid source, still allowing the blocking of much of the forged email that is floating around. The one problem with this is that is does provide a way a spammer could possibly verify that at least some email addresses are valid targets (having non-default SPF records), but maybe that could also be used to setup honeypots.
-- Richard Damon _______________________________________________ Mailman-Developers mailing list Mailman-Developers@python.org https://mail.python.org/mailman/listinfo/mailman-developers Mailman FAQ: http://wiki.list.org/x/AgA3 Searchable Archives: http://www.mail-archive.com/mailman-developers%40python.org/ Unsubscribe: https://mail.python.org/mailman/options/mailman-developers/archive%40jab.org Security Policy: http://wiki.list.org/x/QIA9