the curse of the S(imple) protocols, was: Re: e2e

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On 17-aug-2007, at 14:56, Keith Moore wrote:

It would also restrict you to using a Return-path which is valid for
the network from which you are sending the mail.  That may not be
practical in some environments where you don't have an existing
account and you can only send mail through the local mail server (no
access to submission port on home server, e.g. outgoing TCP 587
blocked or network unreachable).

So what you're saying is that any mail server should be able to source
messages from any mail user using any email address in any domain.

Sorry, that's not a reasonable desire in my opinion.

what's unreasonable is trying to use IP addresses as authentication
tokens, or expecting applications to know about network topology in
order to route messages.

I agree that this suboptimal (but given that simple email users such as myself have so few options my server does take the source IP address into consideration when filtering at this point in time).

What we need to filter on are (of course) the identities of the servers and the originators of messages. But the former requires that servers don't trust random originators, hence my message, and that there is some way to make sure an originator is who he or she claims to be that works a bit better than simply taking the From: line at face value.

The counter argument is that spammers will simply use disposable identities. However, that at least makes sure that if I get a message from ietf@xxxxxxxx I know that it's actually from ietf@xxxxxxxx so whitelisting works and I don't get bombarded with bounces when a spammer uses my domain, and if we make getting an identity take enough time or money, spammers won't be able to get them fast enough to spam much before they're blacklisted.

Then again, misspelled fishing would be an order of magnitude harder if banks and retailers started using S/MIME, which is widely implemented today, but they can't be bothered, so it looks like protocol design isn't going to save the world any time soon.

_______________________________________________

Ietf@xxxxxxxx
https://www1.ietf.org/mailman/listinfo/ietf

[Index of Archives]     [IETF Annoucements]     [IETF]     [IP Storage]     [Yosemite News]     [Linux SCTP]     [Linux Newbies]     [Fedora Users]