Re: Allowing IMAP/POP to Send Email

[Gino Cerullo]

For someone who was worried about breaking forwarding with SPF just a little while ago. What you propose below blows forwarding out of the water.  On 2-Aug-06, at 4:53 PM, Marc Perkel <[EMAIL PROTECTED]> wrote: Allowing IMAP/POP to Send Email The email SMTP protocol was created in simpler times. One of the problems is that it is far too easy for any one person to impersonate any other person on the planet. One of the things that will reduce spam and fraud on the Internet is to make it more difficult for one person to impersonate someone what they aren’t. But to do this we need to change that way email is distributed and do it in a way that is a natural evolution of the current system. In the beginning the Internet was a Unix network where every computer had its own SMTP server. One person would create an email that was submitted to the local SMTP server, the local server contacted the destination SMTP server and that server would deliver the message into the local email box. That method still works today but few people get their email that way. Yes and there use to be a time when every SMTP server was an open relay and you could use any server to send email. Unfortunately criminals are abusing the present system to their advantage and our detriment. Sender --> SMTP --> Recipient Actually the system works like this Sender (SMTP) --> Sender’s Server (SMTP) --> Recipient’s Server (SMTP) --> Recipient (POP/IMAP) Sender --> SMTP --> Recipient (is usually intranet mail or mail sent between recipients of the same domain) which would take the form of Sender (SMTP) --> Sender’s/Recipient’s Server (SMTP) --> Recipient (POP/IMAP) but also allows for  Sender --> SMTP --> SMTP --> SMTP --> Recipient (where there can be any number of intermediate SMTP servers) or Sender --> Forwarding SMTP --> SMTP --> SMTP --> Recipient (where there can be any number of intermediate Forwarding and standalone SMTP servers) It's a real mess! Today we have more of a consumer model where consumers run email clients and leave the SMTP servers to their Internet Service Providers (ISPs) The user creates an email message that is sent to their local ISP who has an SMTP server. That server accepts the email and then transfers the email by SMTP to the server that stores the incoming email for that user. Then the recipient connects to their server by POP/IMAP protocols to download their email. Sender --> SMTP --> Sender’s ISP Server Sender’s ISP Server --> SMTP --> Recipient’s ISP Server Recipient’s ISP Server --> IMAP --> Recipient The problem is that anyone can impersonate any other person by setting their address to be anyone else on the planet. SMTP provides no checking to determine if the sender is the same person as they say they are. And the end user is using the same protocols to talk to servers that servers use to talk to each other so servers can’t tell if they are talking to legitimate servers or end users. I suggest a modification in the IMAP/POP protocols that allow for a two way transfer of email rather than requiring incoming email to be downloaded with IMAP/POP and outgoing to be SMTP. Sender --> IMAP --> Sender’s ISP Server Sender’s ISP Server --> SMTP --> Recipient’s ISP Server Recipient’s ISP Server --> IMAP --> Recipient If IMAP and POP were enhanced to allow outgoing email to be transferred back up the same connection as incoming email it would have several advantages. It would eliminate the need to configure outgoing SMTP. That makes it easier for the consumer. It would also eliminate the need for authenticated SMTP because IMAP/POP are already authenticated protocols. You're just trading IMAP/POP (which isn't designed for what you propose) for SMTP and gaining nothing. What's wrong with authenticated SMTP?  Viruses would not be able to send email because the outgoing email connection, IMAP, will require a password to send email. The virus won’t have the password and won’t be able to send. You can configure your client now to ask for a password before sending email even with authenticated SMTP. It's just that people don't configure it that way because it's inconvenient. Most zombies responsible for sending spam are self contained with mini SMTP servers. So what if you use IMAP/POP, they'll just contain mini versions of that instead. The server would accept outgoing email and label the from field to be the same as the email account preventing the user from pretending to be an email address other than the one the user authenticated as. It would then deliver the message to the local SMTP server which would then send it to the destination server. So you propose configuring every outgoing email server to know every possible return address that an account is allowed to use for outgoing email. I host many domains on my server. How is the server suppose to know which outgoing domain I'm using if it doesn't read it from my email client. And if we leave it to the client to inform the server what email address to stamp the outgoing message with then what's to prevent me from using a forged address.  If I control both the client and server, what's to prevent me from using forged addresses in the scenario above. This method allows the system to assert that the sender’s email address was sent from a person who had the ability to log in and read the email. Thus if you get an email from [EMAIL PROTECTED] then you know that the person sending the email had the username and password to receive email on that account. This is no different then the present system. You either authenticate or you don't. Who cares if it's POP/IMAP or SMTP. It would eliminate virus infected spam zombies from pretending to be SMTP servers because they would no longer be the official source of messages for domains that they pretend to be. It will be easier to create rules that keep servers from impersonating other servers when clients and servers use different protocols.. I don't see how authenticating with POP/IMAP makes this any different than authenticating with SMTP. Protocols like SMTP-AUTH and Submission are no longer necessary. It also eliminates the problem of finding an SMTP server for outgoing email while traveling. If you can read your email under this system, you can send email. Again, I don't see how this is better than authentication with SMTP. You make it sound like not every POP/IMAP server comes with SMTP. And since they do why not use authenticated SMTP to send through the same server? -- Gino Cerullo Pixel Point Studios 21 Chesham Drive Toronto, ON  M3M 1W6 T: 416-247-7740 F: 416-247-7503