Re: [Mailman-Developers] Thinking about list footers
Murray S. Kucherawy writes:
We didn't intend for this to be used by MUAs, however, so to some degree they're doing what we expected.
I know, but I think it's time for the IETF to recognize that email fraud cannot be fought if the receiving end of "end-to-end" doesn't go all the way through the eyeballs, optic nerve, and into the wetware. (Maybe we need an April 1 RFC for neural transport of IP packets first?)
I'm trying to figure out if that would be useful at all, but it sounds like MUAs are the showstopper there.
I sure don't want to give up! Some huge fraction of users must use GMail, Yahoo! mail, AOL, Hotmail, or Outlook for their MUAs. And that should cover the vast majority of "Most Likely to Fall for a Phishing Attack" users. Not that "vast majority" is anything to write home to mother about, but it's a very good start. With Comcast and a couple of others taking potshots at Yahoo!, I'd think the big ESPs are probably ready to take MUA improvement seriously. (Starting with protecting addressbooks, of course, but HCI stuff too I hope.)
Where is Dave Hayes when we so desperately need his AI newsreader?
Steve
On 6/4/14, 4:23 AM, Stephen J. Turnbull wrote:
Murray S. Kucherawy writes:
We didn't intend for this to be used by MUAs, however, so to some degree they're doing what we expected.
I know, but I think it's time for the IETF to recognize that email fraud cannot be fought if the receiving end of "end-to-end" doesn't go all the way through the eyeballs, optic nerve, and into the wetware. (Maybe we need an April 1 RFC for neural transport of IP packets first?) Yes, the only way to truly fight phish is to at least somewhat standardize parts of how a MUA displays some stuff to the user.
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.
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.
This should pretty much get rid of most phish type messages, except those sent by a user compromised machine, and that is something that the email standards really can't help with (how can you expect an email standard to distinguish between email from a program on my machine that I told it to send, and email from possibly the same program that some attacking program told it to send.)
I'm trying to figure out if that would be useful at all, but it sounds like MUAs are the showstopper there.
I sure don't want to give up! Some huge fraction of users must use GMail, Yahoo! mail, AOL, Hotmail, or Outlook for their MUAs. And that should cover the vast majority of "Most Likely to Fall for a Phishing Attack" users. Not that "vast majority" is anything to write home to mother about, but it's a very good start. With Comcast and a couple of others taking potshots at Yahoo!, I'd think the big ESPs are probably ready to take MUA improvement seriously. (Starting with protecting addressbooks, of course, but HCI stuff too I hope.)
Where is Dave Hayes when we so desperately need his AI newsreader?
Steve
-- Richard Damon
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.
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?
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
On 6/4/14, 11:39 AM, Stephen J. Turnbull wrote: 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
On Wed, Jun 4, 2014 at 8:39 AM, Stephen J. Turnbull <stephen@xemacs.org> wrote:
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?
Unless I'm missing something (which is likely given how little caffeine has hit my system so far this morning), this reduces to whitelisting the DKIM signing domain which in this case would be the list operator's domain, correct?
If that's the case, you still have the scaling problem of populating the whitelist. How would Yahoo! go about doing that, for example? They claim at least 30,000 such cases that ideally would land in that list automatically somehow.
-MSK
participants (3)
-
Murray S. Kucherawy -
Richard Damon -
Stephen J. Turnbull