Allowing IMAP/POP to Send Email

[Marc Perkel]

 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.

Sender --> SMTP --> Recipient 

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.
  
  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.
  
  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.
  
  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.
  
  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..
  
  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.
  

Re: Allowing IMAP/POP to Send Email

[Logan Shaw]

On Wed, 2 Aug 2006, Marc Perkel wrote:
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.


 1. 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.


But they don't already exist.  Authenticated SMTP does already exist.
So it's sort of an advantage (I really agree -- the configuration is
a tiny bit easier), but it also has a big disadvantage that common
e-mail clients don't have the capability to do this!


 2. 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.


Yeah, the virus won't have the password.  Unless somebody comes up
with the idea of offering a "remember my password" checkbox on the
dialog that asks for the password.  Then they will have the password.

  - Logan

Re: Allowing IMAP/POP to Send Email

[Logan Shaw]

On Wed, 2 Aug 2006, Marc Perkel wrote:

 3. 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.
 4. 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.


I forgot to mention this in my other message, so I'll mention it now.

You don't, in fact, know that the person sending the message
had "the" username and password for that account.  All you
know is that you received e-mail a server which claims to
have verified the username and password.  You have no way of
knowing whether it actually did.  That is, unless you have
a list of all valid e-mail servers everywhere in the world.
But if you had that, you could just ditch your whole scheme
and only accept e-mail from those servers.

  - Logan

Re: Allowing IMAP/POP to Send Email

[Magnus Holmgren]

On Wednesday 02 August 2006 22:02, Marc Perkel took the opportunity to say:
>   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.

Haven't we been through this already? Switching submission protocols does 
*not* make the sender address more authenticated. Cryptographic signatures 
do, provided that there is infrastructure in place that allows the recipient 
to bind the key that made the signature to a physical person. If you can 
trust the server that handed you the mail (e.g. by help of SPF...), that 
alone can ensure that the sender address is authentic, but you can't trust 
servers in general.

-- 
Magnus Holmgren[EMAIL PROTECTED]
   (No Cc of list mail needed, thanks)


pgp0ZleZnzSiD.pgp
Description: PGP signature

Re: Allowing IMAP/POP to Send Email

[hamann . w]

>> This is a multi-part message in MIME format.
>> --090806020708020808010004
>> Content-Type: text/plain; charset=ISO-8859-1; format=flowed
>> Content-Transfer-Encoding: 7bit
>> 
>> 
>>   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.
>> 
>> Sender --> SMTP --> Recipient 
>> 
>> 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.
>> 
>>1. 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.
>>2. 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.

It seems that for a while malware using outlook to send (via the configured 
connection,
using the configured password) was more widespread than an smtp engine.
This could be a local phenomenon, though.

>>3. 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.
my local isp does that, although the protocol to send is smtp

>>4. 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.
unless someone manages to pretend running a valid smtp service for the sender
domain 
spf and dkim are attempts to verify that a valid smtp server was sending

>>5. It would eliminate virus infected spam zombies from pretending to
>>   be SMTP servers because they 

Re: Allowing IMAP/POP to Send Email

[Jason Haar]

FYI: Courier-IMAP has had this feature for some time. You can configure
it so that any mail message dropped into an IMAP subfolder named (e.g.)
"Outbox" will be auto-sent - i.e. piped into /usr/sbin/sendmail.
Completely removes the need for SMTP.

Of course, it would really require all MUAs to be rewritten to "hide"
this technical backend skulduggery from the end-user. They should just
be able to hit "Send" as usual.

-- 
Cheers

Jason Haar
Information Security Manager, Trimble Navigation Ltd.
Phone: +64 3 9635 377 Fax: +64 3 9635 417
PGP Fingerprint: 7A2E 0407 C9A6 CAF6 2B9F 8422 C063 5EBB FE1D 66D1

Re: Allowing IMAP/POP to Send Email

[jdow]

From: "Marc Perkel" <[EMAIL PROTECTED]>


     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.


Sender --> SMTP --> Recipient 

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.


  1. 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.
  2. 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.
  3. 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.
  4. 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.
  5. 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..
  6. 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.


All this blathering aside please note that SMTP-AUTH exists now. So
there is no need for POP3 send or IMAP send. Your intense concentration
on IMAP send raises sincere questions about your real motivations. IMAP,
after all, exposes user email to scrutiny on machines the user does not
control. It also severely limits the amount of storage a user can devote
to email. I prefer to use a lot of storage because I like to go back and
look for data I had at one point considered worth saving. It is easier to
store it in the email tool than to save each individual message in a
series of folders for manual access via tools not well adapted to reading
email.

You irrationally hate SMTP. Since you are approaching this project from
this biased posit

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 EmailThe 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 thisSender (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 ofSender (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)orSender --> 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 t

Re: Allowing IMAP/POP to Send Email

[jdow]

From: "Logan Shaw" <[EMAIL PROTECTED]>

On Wed, 2 Aug 2006, Marc Perkel wrote:
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.


 1. 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.


But they don't already exist.  Authenticated SMTP does already exist.
So it's sort of an advantage (I really agree -- the configuration is
a tiny bit easier), but it also has a big disadvantage that common
e-mail clients don't have the capability to do this!


 2. 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.


Yeah, the virus won't have the password.  Unless somebody comes up
with the idea of offering a "remember my password" checkbox on the
dialog that asks for the password.  Then they will have the password.


Sniffers exist. Passwords are NOT the solution. They may evolve into
part of the problem.

Traffic analysis and slow downs for sending too many emails too
rapidly are part of the solution. Forcing authenticated SMTP submission
finishes the solution. The authenticated SMTP exists now. It has
password problems via simple sniffing. I wish Earthlink supported
SSL connections which can't be sniffed. That at least raises the
password ante a little. The slow down technology exists. Earthlink
claimed to be using it something like a decade ago. If the data
extracted from the slow down technology is used to simply shut off
accounts that are spewing, in real time, zombie spam would be materially
reduced. Automated submission of spewing addresses to Block Lists
from larger ISPs that can notice the patterns would also help everyone.

But mere passwords on unsecure protocols are no really big deal other
than it, theoretically, points to a specific machine that can be shut
down. (Since zombies share data it'll be a short time before this also
becomes mooted.)

There is no "solution" there is only measure and counter-measure as
both sides get better at what they want to do. Selling snake oil about
POP3 or IMAP email submission is just plain amateurish stupidity if it
is not driven by an ulterior motive.

{^_^}

Re: Allowing IMAP/POP to Send Email

[Gino Cerullo]

On 2-Aug-06, at 6:29 PM, Jason Haar <[EMAIL PROTECTED]> wrote:FYI: Courier-IMAP has had this feature for some time. You can configure it so that any mail message dropped into an IMAP subfolder named (e.g.) "Outbox" will be auto-sent - i.e. piped into /usr/sbin/sendmail. Completely removes the need for SMTP.  Of course, it would really require all MUAs to be rewritten to "hide" this technical backend skulduggery from the end-user. They should just be able to hit "Send" as usual.  --  Cheers  Jason Haar Information Security Manager, Trimble Navigation Ltd. Phone: +64 3 9635 377 Fax: +64 3 9635 417 PGP Fingerprint: 7A2E 0407 C9A6 CAF6 2B9F 8422 C063 5EBB FE1D 66D1  If it's piped into '/usr/sbin/sendmail' then it is still using SMTP. Sendmail is an SMTP server.--Gino CerulloPixel Point Studios21 Chesham DriveToronto, ON  M3M 1W6T: 416-247-7740F: 416-247-7503 

Re: Allowing IMAP/POP to Send Email

[Gino Cerullo]

On 2-Aug-06, at 7:29 PM, [EMAIL PROTECTED] wrote:Sniffers exist. Passwords are NOT the solution. They may evolve into part of the problem.  Traffic analysis and slow downs for sending too many emails too rapidly are part of the solution. Forcing authenticated SMTP submission finishes the solution. The authenticated SMTP exists now. It has password problems via simple sniffing. I wish Earthlink supported SSL connections which can't be sniffed. That at least raises the password ante a little. They probably don't want to use SSL because that encrypts the whole communication even the body of the message. That might be noticeable on older, slow computers their clients may still be using if they are sending a message with a large attachment. A better authentication method would just encrypt the account name and password but Outlook/Outlook Express, arguably the most used email clients, don't support anything but MS's own proprietary technology for doing that.The slow down technology exists. Earthlink claimed to be using it something like a decade ago. If the data extracted from the slow down technology is used to simply shut off accounts that are spewing, in real time, zombie spam would be materially reduced. Automated submission of spewing addresses to Block Lists from larger ISPs that can notice the patterns would also help everyone.  But mere passwords on unsecure protocols are no really big deal other than it, theoretically, points to a specific machine that can be shut down. (Since zombies share data it'll be a short time before this also becomes mooted.)  There is no "solution" there is only measure and counter-measure as both sides get better at what they want to do. Selling snake oil about POP3 or IMAP email submission is just plain amateurish stupidity if it is not driven by an ulterior motive.  {^_^}  --Gino CerulloPixel Point Studios21 Chesham DriveToronto, ON  M3M 1W6T: 416-247-7740F: 416-247-7503 

smime.p7s
Description: S/MIME cryptographic signature

Re: Allowing IMAP/POP to Send Email

[jdow]

From: "Gino Cerullo" <[EMAIL PROTECTED]>

On 2-Aug-06, at 7:29 PM, [EMAIL PROTECTED]  
wrote:



Sniffers exist. Passwords are NOT the solution. They may evolve into
part of the problem.

Traffic analysis and slow downs for sending too many emails too
rapidly are part of the solution. Forcing authenticated SMTP  
submission

finishes the solution. The authenticated SMTP exists now. It has
password problems via simple sniffing. I wish Earthlink supported
SSL connections which can't be sniffed. That at least raises the
password ante a little.


They probably don't want to use SSL because that encrypts the whole  
communication even the body of the message. That might be noticeable  
on older, slow computers their clients may still be using if they are  
sending a message with a large attachment. A better authentication  
method would just encrypt the account name and password but Outlook/ 
Outlook Express, arguably the most used email clients, don't support  
anything but MS's own proprietary technology for doing that.


The message does reside, briefly, on the servers wide open to reading.
But this does make it impossible for wiretaps to intercept it. Since a
wire tap is a "dual use" technology, criminals can use it as easily as
the government, they should be prevented. It is much harder for the
criminals to intercept while on the server unless it is a VERY inside
job. And I'm just crazy enough that if someone has to intercept my
email at all I'd rather it was the government than the bag guys. The
latter are proven evil. The government is mostly fumbling clumsy more
than active evil for the average person out there.

And, yes, I do find it interesting that Earthlink and others do NOT
support secure POP3 and secure authenticated SMTP at least. It raises
lots of questions to one who is just paranoid to believe "'They' are
out to get me; but, it's nothing personal, any victim will do."

{^_^}   Joanne

Re: Allowing IMAP/POP to Send Email

[John D. Hardin]

On Wed, 2 Aug 2006, jdow wrote:

> IMAP, after all, exposes user email to scrutiny on machines the
> user does not control.

Now, be fair. SMTP has exactly the same weakness. What prevents the
Earthlink SMTP servers from saving a copy of every message they
process on your behalf?

If you want your email to truly be secure and private, the ***ONLY***
way is to encrypt the body text. Anything else (e.g. privacy laws) is
merely security theatre.

--
 John Hardin KA7OHZICQ#15735746http://www.impsec.org/~jhardin/
 [EMAIL PROTECTED]FALaholic #11174pgpk -a [EMAIL PROTECTED]
 key: 0xB8732E79 - 2D8C 34F4 6411 F507 136C  AF76 D822 E6E6 B873 2E79
---
  The problem is when people look at Yahoo, slashdot, or groklaw and
  jump from obvious and correct observations like "Oh my God, this
  place is teeming with utter morons" to incorrect conclusions like
  "there's nothing of value here".-- Al Petrofsky, in Y! SCOX
---

Re: Allowing IMAP/POP to Send Email

[John D. Hardin]

On Wed, 2 Aug 2006, jdow wrote:

> The authenticated SMTP exists now. It has password problems via
> simple sniffing. I wish Earthlink supported SSL connections which
> can't be sniffed.

TLS?

--
 John Hardin KA7OHZICQ#15735746http://www.impsec.org/~jhardin/
 [EMAIL PROTECTED]FALaholic #11174pgpk -a [EMAIL PROTECTED]
 key: 0xB8732E79 - 2D8C 34F4 6411 F507 136C  AF76 D822 E6E6 B873 2E79
---
  The problem is when people look at Yahoo, slashdot, or groklaw and
  jump from obvious and correct observations like "Oh my God, this
  place is teeming with utter morons" to incorrect conclusions like
  "there's nothing of value here".-- Al Petrofsky, in Y! SCOX
---

Re: Allowing IMAP/POP to Send Email

[jdow]

From: "John D. Hardin" <[EMAIL PROTECTED]>


On Wed, 2 Aug 2006, jdow wrote:


The authenticated SMTP exists now. It has password problems via
simple sniffing. I wish Earthlink supported SSL connections which
can't be sniffed.


TLS?


They don't have that either.
{^_^}

Re: Allowing IMAP/POP to Send Email

[Marc Perkel]

Gino Cerullo wrote:

  
  On 2-Aug-06, at 6:29 PM, Jason Haar <[EMAIL PROTECTED]>
wrote:
  
  
FYI: Courier-IMAP has had this feature for
some time. You can configure
it so that any mail message dropped into an
IMAP subfolder named (e.g.)
"Outbox" will be auto-sent - i.e. piped into
/usr/sbin/sendmail.
Completely removes the need for SMTP.


Of course, it would really require all MUAs
to be rewritten to "hide"
this technical backend skulduggery from the
end-user. They should just
be able to hit "Send" as usual.


-- 
Cheers


Jason Haar
Information Security Manager, Trimble
Navigation Ltd.
Phone: +64 3 9635 377 Fax: +64 3 9635 417
PGP Fingerprint: 7A2E 0407 C9A6 CAF6 2B9F
8422 C063 5EBB FE1D 66D1
  
  
  
   
  If it's piped into '/usr/sbin/sendmail' then it is still using
SMTP. Sendmail is an SMTP server.
  
  
  
  
  


Yes - that is the plan. You use POP/IMAP to transport the message to
the server when it is piped into SMTP. The idea isn't for IMAP to
deliver the email. It is just a transport to get the message from the
client back to the server when it is sent via SMTP.

I'm not against SMTP. I'm just trying to say that it isn't the best
choice to get the message from the client when you already have an
authenticated connection to the server established.

Re: Allowing IMAP/POP to Send Email

[jdow]

From: "Marc Perkel" <[EMAIL PROTECTED]>


Gino Cerullo wrote:


On 2-Aug-06, at 6:29 PM, Jason Haar <[EMAIL PROTECTED] 
> wrote:



FYI: Courier-IMAP has had this feature for some time. You can configure

it so that any mail message dropped into an IMAP subfolder named (e.g.)

"Outbox" will be auto-sent - i.e. piped into /usr/sbin/sendmail.

Completely removes the need for SMTP.


Of course, it would really require all MUAs to be rewritten to "hide"

this technical backend skulduggery from the end-user. They should just

be able to hit "Send" as usual.


--

Cheers


Jason Haar

Information Security Manager, Trimble Navigation Ltd.

Phone: +64 3 9635 377 Fax: +64 3 9635 417

PGP Fingerprint: 7A2E 0407 C9A6 CAF6 2B9F 8422 C063 5EBB FE1D 66D1



If it's piped into '/usr/sbin/sendmail' then it is still using SMTP. 
Sendmail is an SMTP server.





Yes - that is the plan. You use POP/IMAP to transport the message to the 
server when it is piped into SMTP. The idea isn't for IMAP to deliver 
the email. It is just a transport to get the message from the client 
back to the server when it is sent via SMTP.


I'm not against SMTP. I'm just trying to say that it isn't the best 
choice to get the message from the client when you already have an 
authenticated connection to the server established.


Quite clearly you ARE against SMTP. And quite clearly you do not in
the least understand it as a tool. So far you've not demonstrated any
serious knowledge of the protocols involved or the available, WIDELY
available, existing tools that will not force users to upgrade and
adopt unwieldy awkward substitute tools.

How is the server supposed to know that incoming mail in SMTP format
is not from a genuine server? You've not addressed this point. Blocking
port 25 is not going to work. Too many businesses rely on their own
mail servers rather than ISP servers. This is true even of single
person consultancy businesses.

And please note very carefully, at present I do NOT fetch my mail from
the same servers as I use to submit my mail when using my MUA. I pull
the mail down to a Linux machine, run SpamAssassin there with rules
and BAYES selected for the needs at this precise location and the
precise accounts on the machine at this location. Then I submit my
email via port 587 to Earthlink's authenticated SMTP port, which
requires the same password and ID as the POP3 port or any IMAP port
that might exist. So I am not tied to a bottleneck. I can prefilter
my email before I try to read it rather than putting SpamAssassin in
the read path for POP3 or IMAP, which causes quite noticeable delays.
Those delays make over 1000 emails a day an untenable option. Your
idea would break my system. And any organization that would suggest
this would guarantee I am its fervent enemy. I'd work to tear down
that organization and disperse its members from this country. I'd
also, if that organization happened to be the UN, use its former
property as homeless shelters. The idea you are espousing so fervently
is an extraordinarily stupid idea.

{^_^}Joanne said that and meant it.

Re: Allowing IMAP/POP to Send Email

[John Andersen]

On Wednesday 02 August 2006 12:02, Marc Perkel wrote:

Long pedantic diatribe deleted   (Really, don't you suppose anyone reading
this list knew all of that already)?

>  1. 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.

Authenticated smtp is no harder on the user with today's MUAs than is pop.

ISPs simply took the EASY way out of setting their  networks as trusted and 
everybody else as un-trusted. Those that went the extra mile to get smtpauth
working are few and far between, but you can find them.  I have a hosting
company which allows smtp as long as its authorized.

>    2. Viruses would not be able to send email because the outgoing email
>       connection, IMAP, will require a password to send email.
 
And that inability would last HOW Long?

-- 
_
John Andersen


pgpVSX6SsHdG6.pgp
Description: PGP signature

Re: Allowing IMAP/POP to Send Email

[Tony Finch]

The reason that message submission is done with SMTP is because of the
number of SMTP extensions that the MUA will want to use, in particular
DSNs, deliver-by, deliver-after, message tracking, and whatever else may
be invented in the future. If you want to make message submission a part
of IMAP and POP then you'll have to re-do all these SMTP extensions twice,
which is a colossal waste of time.


On Wed, 2 Aug 2006, Marc Perkel wrote:

>   2. 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.

Not true. The virus controls the machine so it can obtain the user's
password. In any case, and as many people have already pointed out, you
can authenticate SMTP as well as you can IMAP.

>   4. 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.

Also true for authenticated SMTP.

>   5. 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 would not. They could still talk SMTP or steal users' login
credentials.

Tony.
-- 
f.a.n.finch  <[EMAIL PROTECTED]>  http://dotat.at/
FISHER: WEST OR NORTHWEST 4 OR 5 BECOMING VARIABLE 3 OR 4. FAIR. MODERATE OR
GOOD.

Re: Allowing IMAP/POP to Send Email

[Marc Perkel]

Tony Finch wrote:

The reason that message submission is done with SMTP is because of the
number of SMTP extensions that the MUA will want to use, in particular
DSNs, deliver-by, deliver-after, message tracking, and whatever else may
be invented in the future. If you want to make message submission a part
of IMAP and POP then you'll have to re-do all these SMTP extensions twice,
which is a colossal waste of time.


  


Not really - what I'm proposing is that the IMAP connection just pipe 
the message into an SMTP server. The IMAP is acting only and an 
authenticated connection back to SMTP. I'm not suggesting replacing 
SMTP. What I'm suggesting is that POP/IMAP can be used as a transport to 
get the mail there because it's an existing connection, is already 
established, is already authenticated with the credentials of the email 
account, and it isn't a port that people would block like port 25 is.


I'm not trying to replace SMTP. I'm just trying to suggest a better way 
for end users to get outgoing email to the SMTP server.

Re: Allowing IMAP/POP to Send Email

[Chris Lear]

* Marc Perkel wrote (03/08/06 14:39):


Tony Finch wrote:

The reason that message submission is done with SMTP is because of the
number of SMTP extensions that the MUA will want to use, in particular
DSNs, deliver-by, deliver-after, message tracking, and whatever else may
be invented in the future. If you want to make message submission a part
of IMAP and POP then you'll have to re-do all these SMTP extensions twice,
which is a colossal waste of time.


  


Not really - what I'm proposing is that the IMAP connection just pipe 
the message into an SMTP server. The IMAP is acting only and an 
authenticated connection back to SMTP. I'm not suggesting replacing 
SMTP. What I'm suggesting is that POP/IMAP can be used as a transport to 
get the mail there because it's an existing connection, is already 
established, is already authenticated with the credentials of the email 
account, and it isn't a port that people would block like port 25 is.


I'm not trying to replace SMTP. I'm just trying to suggest a better way 
for end users to get outgoing email to the SMTP server.




What if I set up an SMTP server at home behind my ADSL router, collect 
my vanity-domain mail there, and access it via IMAP or POP3? It seems I 
only have one option, which is to send my mail via IMAP to my home 
server. Which then sends via SMTP to... the Internet (or via a 
smarthost). And the home server sending via SMTP is going to look a bit 
like a MUA sending via SMTP. How would you tell the difference? Is a 
home mail server outlawed in the brave new world? Or does my SMTP server 
have to learn to talk IMAP to make message submissions to the ISP's server?


Chris

Re: Allowing IMAP/POP to Send Email

[Logan Shaw]

On Thu, 3 Aug 2006, Marc Perkel wrote:
Not really - what I'm proposing is that the IMAP connection just pipe the 
message into an SMTP server. The IMAP is acting only and an authenticated 
connection back to SMTP. I'm not suggesting replacing SMTP. What I'm 
suggesting is that POP/IMAP can be used as a transport to get the mail there 
because it's an existing connection, is already established, is already 
authenticated with the credentials of the email account, and it isn't a port 
that people would block like port 25 is.


I'm not trying to replace SMTP. I'm just trying to suggest a better way for 
end users to get outgoing email to the SMTP server.


Yes.  You've already said that.  What you're trying to do
is create an internet where SMTP traffic only occurs between
legitimate servers.  You then claim that if such an internet
existed, there would be a huge impact against spam.  I have
to concur that if that were true, spam would be greatly reduced.

Here's the problem though.  We've got a logical syllogism here:
"If X, then Y."  The "X" is "only legitimate servers speak
SMTP", and the "Y" is "spam will be greatly reduced".

I agree that the "if X, then Y" part of this argument is
sound.  The problem is, for Y to logically follow, you have
to establish X.  A syllogism works like this:

1.  If X, then Y.
2.  X is known to be true.
3.  Therefore, Y is true.

Part 1 is called the major premise.  Part 2 is called the
minor premise.  Part 3 is the conclusion.

Your argument is missing the minor premise.  You have to
establish the minor premise or your argument will have no
validity.

So then, do you wish to give up on your argument, or do you
wish to explain how you're going to accomplish this feat of
making sure that only legitimate servers try to contact other
servers via SMTP?

  - Logan

Re: Allowing IMAP/POP to Send Email

[Marc Perkel]

Chris Lear wrote:



What if I set up an SMTP server at home behind my ADSL router, collect 
my vanity-domain mail there, and access it via IMAP or POP3? It seems 
I only have one option, which is to send my mail via IMAP to my home 
server. Which then sends via SMTP to... the Internet (or via a 
smarthost). And the home server sending via SMTP is going to look a 
bit like a MUA sending via SMTP. How would you tell the difference? Is 
a home mail server outlawed in the brave new world? Or does my SMTP 
server have to learn to talk IMAP to make message submissions to the 
ISP's server?


Chris



Then it would be a server and talk SMTP. Servers still talk SMTP. I have 
a home SMTP server myself.

Re: Allowing IMAP/POP to Send Email

[Marc Perkel]

Logan Shaw wrote:

On Thu, 3 Aug 2006, Marc Perkel wrote:
Not really - what I'm proposing is that the IMAP connection just pipe 
the message into an SMTP server. The IMAP is acting only and an 
authenticated connection back to SMTP. I'm not suggesting replacing 
SMTP. What I'm suggesting is that POP/IMAP can be used as a transport 
to get the mail there because it's an existing connection, is already 
established, is already authenticated with the credentials of the 
email account, and it isn't a port that people would block like port 
25 is.


I'm not trying to replace SMTP. I'm just trying to suggest a better 
way for end users to get outgoing email to the SMTP server.


Yes.  You've already said that.  What you're trying to do
is create an internet where SMTP traffic only occurs between
legitimate servers.  You then claim that if such an internet
existed, there would be a huge impact against spam.  I have
to concur that if that were true, spam would be greatly reduced.

Here's the problem though.  We've got a logical syllogism here:
"If X, then Y."  The "X" is "only legitimate servers speak
SMTP", and the "Y" is "spam will be greatly reduced".

I agree that the "if X, then Y" part of this argument is
sound.  The problem is, for Y to logically follow, you have
to establish X.  A syllogism works like this:

1.  If X, then Y.
2.  X is known to be true.
3.  Therefore, Y is true.

Part 1 is called the major premise.  Part 2 is called the
minor premise.  Part 3 is the conclusion.

Your argument is missing the minor premise.  You have to
establish the minor premise or your argument will have no
validity.

So then, do you wish to give up on your argument, or do you
wish to explain how you're going to accomplish this feat of
making sure that only legitimate servers try to contact other
servers via SMTP?

  - Logan



Spam is never eliminated - just reduced. Most spam comes from virus 
infected zombies that talk SMTP. If end users were by default set up so 
that they can only send email by IMAP then you can block off SMTP ports 
for end users isolating them from the SMTP world. That would take a huge 
bite out of the spam problem.

Re: Allowing IMAP/POP to Send Email

[JamesDR]

Marc Perkel wrote:
Spam is never eliminated - just reduced. Most spam comes from virus 
infected zombies that talk SMTP. If end users were by default set up so 
that they can only send email by IMAP then you can block off SMTP ports 
for end users isolating them from the SMTP world. That would take a huge 
bite out of the spam problem.



For about a day. Spam software writers aren't stupid. All the standards 
that would be necessary for this kind of system to work on a broad scale 
would have to be open. By the time you got every ISP in one slice of the 
world to do this, then this will be exploited. My own home ISP had this 
happen to them. Bellsouth (in my area at least) blocked both 25 out and 
25 in. We had to send through Bellsouth's mail server. At first it was 
configured as an open relay for their customers. Then you had to 
authenticate. After they enabled authentication, I haven't seen a single 
Bellsouth DSL originating email spam (from the res blocks.) If others 
have, chime in. But from what I see, this works. It did anger me at 
first because they didn't tell their customers, and when directly asked 
they denied doing such (maybe just their help desk drones didn't know.) 
Anyway. Block 25, require auth to the isp's server. Done. SMTP-AUTH 
would be EXACTLY the same as what you purpose. Here's an idea. Quit 
waisting your time here. You haven't found any supporters here. Try 
security lists. Write a letter to your ISP, your friend's ISP, your 
place of business's ISP and see what they say. I bet they'll say "Not 
feasible -- SMTP-AUTH works just fine"


--
Thanks,
James

Re: Allowing IMAP/POP to Send Email

[Magnus Holmgren]

On Thursday 03 August 2006 19:25, Marc Perkel took the opportunity to say:
> Chris Lear wrote:
> > What if I set up an SMTP server at home behind my ADSL router, collect
> > my vanity-domain mail there, and access it via IMAP or POP3? It seems
> > I only have one option, which is to send my mail via IMAP to my home
> > server. Which then sends via SMTP to... the Internet (or via a
> > smarthost). And the home server sending via SMTP is going to look a
> > bit like a MUA sending via SMTP. How would you tell the difference? Is
> > a home mail server outlawed in the brave new world? Or does my SMTP
> > server have to learn to talk IMAP to make message submissions to the
> > ISP's server?
> >
> Then it would be a server and talk SMTP. Servers still talk SMTP. I have
> a home SMTP server myself.

Ooookaaay... but they have to use SMTP AUTH, right? So why can't MUAs talk 
SMTP as well then? The only reason you have left is that you want to remove 
existing functionality (SMTP) from MUAs and replace it with something (two 
things, even) that doesn't yet exist (mail submission over POP and IMAP).

-- 
Magnus Holmgren[EMAIL PROTECTED]
   (No Cc of list mail needed, thanks)


pgpjVGA2O2fNe.pgp
Description: PGP signature

Re: Allowing IMAP/POP to Send Email

[Steve Thomas]

> Spam is never eliminated - just reduced. Most spam comes from virus
> infected zombies that talk SMTP. If end users were by default set up so
> that they can only send email by IMAP then you can block off SMTP ports
> for end users isolating them from the SMTP world. That would take a huge
> bite out of the spam problem.

Which is something that many ISPs and corporations already do. What makes
you think that any more of them will do it if your plan were to be
implemented?

Responsible networks are already blocking port 25, while irresponsible
networks (generalizing to make a point) aren't. What's going to happen to
make the irresponsible networks change their ways? Why hasn't it happened
already? What kind of incentive does your plan specifically provide to
help change those network owners' minds?

Re: Allowing IMAP/POP to Send Email

[jdow]

From: "Marc Perkel" <[EMAIL PROTECTED]>


Chris Lear wrote:



What if I set up an SMTP server at home behind my ADSL router, collect 
my vanity-domain mail there, and access it via IMAP or POP3? It seems 
I only have one option, which is to send my mail via IMAP to my home 
server. Which then sends via SMTP to... the Internet (or via a 
smarthost). And the home server sending via SMTP is going to look a 
bit like a MUA sending via SMTP. How would you tell the difference? Is 
a home mail server outlawed in the brave new world? Or does my SMTP 
server have to learn to talk IMAP to make message submissions to the 
ISP's server?


Chris



Then it would be a server and talk SMTP. Servers still talk SMTP. I have 
a home SMTP server myself.


Yoohoo, Marc! What is the difference between a home SMTP server YOU
run and one that is included in malware that has turned your machine
into a Zombie?

It your specific network arrangement is to be supported then you are
allowing port 25 connections between your server and others. Thus you
have done absolutely nothing to reduce spam. You've only cost people
money changing their entire mail setups end to end.

{^_^}

Re: Allowing IMAP/POP to Send Email

[jdow]

From: "Marc Perkel" <[EMAIL PROTECTED]>

Logan Shaw wrote:

On Thu, 3 Aug 2006, Marc Perkel wrote:
Not really - what I'm proposing is that the IMAP connection just pipe 
the message into an SMTP server. The IMAP is acting only and an 
authenticated connection back to SMTP. I'm not suggesting replacing 
SMTP. What I'm suggesting is that POP/IMAP can be used as a transport 
to get the mail there because it's an existing connection, is already 
established, is already authenticated with the credentials of the 
email account, and it isn't a port that people would block like port 
25 is.


I'm not trying to replace SMTP. I'm just trying to suggest a better 
way for end users to get outgoing email to the SMTP server.


Yes.  You've already said that.  What you're trying to do
is create an internet where SMTP traffic only occurs between
legitimate servers.  You then claim that if such an internet
existed, there would be a huge impact against spam.  I have
to concur that if that were true, spam would be greatly reduced.

Here's the problem though.  We've got a logical syllogism here:
"If X, then Y."  The "X" is "only legitimate servers speak
SMTP", and the "Y" is "spam will be greatly reduced".

I agree that the "if X, then Y" part of this argument is
sound.  The problem is, for Y to logically follow, you have
to establish X.  A syllogism works like this:

1.  If X, then Y.
2.  X is known to be true.
3.  Therefore, Y is true.

Part 1 is called the major premise.  Part 2 is called the
minor premise.  Part 3 is the conclusion.

Your argument is missing the minor premise.  You have to
establish the minor premise or your argument will have no
validity.

So then, do you wish to give up on your argument, or do you
wish to explain how you're going to accomplish this feat of
making sure that only legitimate servers try to contact other
servers via SMTP?

  - Logan



Spam is never eliminated - just reduced. Most spam comes from virus 
infected zombies that talk SMTP. If end users were by default set up so 
that they can only send email by IMAP then you can block off SMTP ports 
for end users isolating them from the SMTP world. That would take a huge 
bite out of the spam problem.


But then your network's SMTP server cannot talk to any other SMTP
server. You have to use a properly sanctioned one. THINK man. THINK.

{^_^}

Allowing IMAP/POP to Send Email & United Nations etc....

[Nigel Frankcom]

I'll put on my flameproof underwear for this

There's been a huge amount of crossfire on these/this subject, but I
don't see how it has anything to do with SA; or am I missing the
point?

Different protocols, yet another level of policing, but nothing about
the fact that SA does a damned fine job of stopping what exists now,
not what may or may not happen (n) years in the future.

Just my 2 pence worth

Nigel

Re: Allowing IMAP/POP to Send Email & United Nations etc....

[Dhawal Doshy]

Nigel Frankcom wrote:

I'll put on my flameproof underwear for this

There's been a huge amount of crossfire on these/this subject, but I
don't see how it has anything to do with SA; or am I missing the
point?

Different protocols, yet another level of policing, but nothing about
the fact that SA does a damned fine job of stopping what exists now,
not what may or may not happen (n) years in the future.

Just my 2 pence worth


2 more units of whatever currency.. kill the threads. NOW!!

Re: Allowing IMAP/POP to Send Email & United Nations etc....

[Michael Parker]

Nigel Frankcom wrote:
> I'll put on my flameproof underwear for this
> 
> There's been a huge amount of crossfire on these/this subject, but I
> don't see how it has anything to do with SA; or am I missing the
> point?
> 
> Different protocols, yet another level of policing, but nothing about
> the fact that SA does a damned fine job of stopping what exists now,
> not what may or may not happen (n) years in the future.
> 
> Just my 2 pence worth
> 
> Nigel
> 

google "marc perkel"

My $.02

Michael