Subject: Re: Apps-Discuss Digest, Vol 19, Issue 6

From: Ravi shankar <[email-masked]>
Date: Sun, 16 Aug 2009 01:13:26 +0530

Okay, that's what i was looking for. Also the idea behind making IMAP/POP3
send mails is that if we can seperate SMTP for purely server level
communication, we can completely eliminate it from end -user communication
and block the ports completely, be it 25 or 587.

Regards,
Ravi

On Sun, Aug 16, 2009 at 12:30 AM, <[email-masked]> wrote:

> If you have received this digest without all the individual message
> attachments you will need to update your digest options in your list
> subscription.  To do so, go to
>
> https://www.ietf.org/mailman/listinfo/apps-discuss
>
> Click the 'Unsubscribe or edit options' button, log in, and set "Get
> MIME or Plain Text Digests?" to MIME.  You can set this option
> globally for all the list digests you receive at this point.
>
>
>
> Send Apps-Discuss mailing list submissions to
>        [email-masked]
>
> To subscribe or unsubscribe via the World Wide Web, visit
>        https://www.ietf.org/mailman/listinfo/apps-discuss
> or, via email, send a message with subject or body 'help' to
>        [email-masked]
>
> You can reach the person managing the list at
>        [email-masked]
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of Apps-Discuss digest..."
>
>
> Today's Topics:
>
>   1. Re: Feasibility research request: POP3 and IMAP4 extension to
>      send      mail (Alessandro Vesely)
>
>
> ----------------------------------------------------------------------
>
> Message: 1
> Date: Sat, 15 Aug 2009 07:40:32 +0400
> From: Alessandro Vesely <[email-masked]>
> Subject: Re: Feasibility research request: POP3 and IMAP4 extension to
>        send    mail
> To: [email-masked]
> Message-ID: <[email-masked]>
> Content-Type: text/plain; charset=ISO-8859-1; format=flowed
>
> Ravi shankar wrote:
> > Need your valuable inputs on the subject of ability to extend the POP3
> > and IMAP4 to send mails, in addition to retrieving mails.
> >
> > I'm currently doing a research on this topic and would like to have your
> > valuable feedbacks on the possibility and probably hinderance in terms
> > of any step in the process.
>
> The server I'm now using has this possibility configured, as
> described in http://www.courier-mta.org/install.html#imapsend
>
> I found no conceptual nor practical difficulty with it, but use
> it seldom.
>
>
> ------------------------------
>
> _______________________________________________
> Apps-Discuss mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/apps-discuss
>
>
> End of Apps-Discuss Digest, Vol 19, Issue 6
> *******************************************
>

---

From: Philip Guenther <[email-masked]>
Date: Sat, 15 Aug 2009 15:20:03 -0700

On Sun, 16 Aug 2009, Ravi shankar wrote:
> Okay, that's what i was looking for. Also the idea behind making 
> IMAP/POP3 send mails is that if we can seperate SMTP for purely server 
> level communication, we can completely eliminate it from end -user 
> communication and block the ports completely, be it 25 or 587.

Why would that (not using SMTP or submission for submission) be a good
thing?  What problem are you trying to address that exists with a current
setup where clients use submission?  What would prevent that problem from
not immediately reoccuring with the new submission mechanism?

(For example, if rogue programs are currently stealing credentials to use
authenticated submission to send email, why would they do the exact same
thing with submission over IMAP/POP3?)

The Lemonade working group went around this topic several years ago and
decided against doing submission through IMAP/POP3 after considering a
number of deployment scenarios and the security issues around them and
instead developed RFCs 4467, 4468, and 4469.  The problem being addresses
there was that of "forward without download", though firewall traveral was
part of the discussion.

A key point in the discussion then was that SMTP and submission are
extensible and many extensions are in use.  Any new submission method
would face having to replicate those extensions *and all future ones* or
drive people back to SMTP.  The obvious solution to that would be to make
the "submission via IMAP/POP3" method 'simply' involve tunneling SMTP
through the other protocol.  That creates myriad security issues and
increases the complexity of implementation greatly, as the state diagram
for the IMAP/POP3 server suddenly has the SMTP state diagram grafted on to
it.  Anyway, I urge you review the archives of that discussion to see
whether your arguments for putting submission inside IMAP/POP3 were
considered then and if so, whether the counter-arguments still apply.

An engineering decision was made then based on the discussion; what has
changed that would strengthen or weaken the arguments that went into that
decision?

Philip Guenther

--
Chief Architect
Sendmail, Inc.

---

From: Ravi shankar <[email-masked]>
Date: Sun, 16 Aug 2009 15:07:11 +0530

Philip,

It's not the authentication mechanism that I'm proposing to change, but
rather the method in which the mails are transsacted in today's setup.

In the present setup, SMTP can be used by any computer connected to Internet
to send mails directly to the server, resulting in spam which by normal
means in indistinguishable from legitimate mails.

What Botnets take advantage of is the fact that a normal Client computer
(say, a home PC) can be infected to send spam. Instead if we classify, SMTP
as the sole "Server to Server" protocol, it gives us the liberty to block
those ports completely in the home/client computers.

In order to allow the client computers that use POP3 and IMAP clients to
continue transacting mails with SMTP blocked, we can extend them  to submit
messages as well.

While this way is not meant to protect against spam created by user
name/password or identity theft, it is specifically aimed at controlling
botnet spread spam, which accounts of 100 billion spam emails a day!.

Regards,
Ravi
On Sun, Aug 16, 2009 at 3:50 AM, Philip Guenther
<[email-masked]<[email-masked]>
> wrote:

---

From: John C Klensin <[email-masked]>
Date: Sun, 16 Aug 2009 13:47:39 -0400

--On Sunday, August 16, 2009 15:07 +0530 Ravi shankar
<[email-masked]> wrote:

>...
> In the present setup, SMTP can be used by any computer
> connected to Internet to send mails directly to the server,
> resulting in spam which by normal means in indistinguishable
> from legitimate mails.
> 
> What Botnets take advantage of is the fact that a normal
> Client computer (say, a home PC) can be infected to send spam.
> Instead if we classify, SMTP as the sole "Server to Server"
> protocol, it gives us the liberty to block those ports
> completely in the home/client computers.

But that is the exact problem that the use of RFC 4409 Message
Submission, including its authentication requirement, is
intended to solve.  It is already widely deployed, does not
require another new protocol, and does not require adding
complexity to POP and IMAP (as others have pointed out).

> In order to allow the client computers that use POP3 and IMAP
> clients to continue transacting mails with SMTP blocked, we
> can extend them  to submit messages as well.
> 
> While this way is not meant to protect against spam created by
> user name/password or identity theft, it is specifically aimed
> at controlling botnet spread spam, which accounts of 100
> billion spam emails a day!.

I believe that what people are telling you is that we already
have a solution to the problem you are proposing to solve.  It
is a solution that is implemented, deployed, in fairly wide use
in some parts of the world.  It is also one that requires very
little change to deployed clients -- for the typical POP3 or
IMAP MUA, all that is needed to support Submit is to change the
outgoing port and enable SMTP authentication... and both
facilities are present in all modern MUAs.

So it seems to me that you need to demonstrate that your
suggestion will work better than continued and broaded use of
Submit, not merely that it would address part of the botnet
problem... more or less the same part that Submit addresses
already.

It also seems to me that part of your analysis suffers from the
same problem as many other analyses of this type and raises
another issue you should address.  The bad guys running botnets
to send spam are ultimately much like the rest of us -- they
aren't going to develop and use complex methods to solve
problems when simple ones will do.  So the botnets use port 25
because it is easy.  There is no reason to believe that, if one
pushes message posting onto IMAP or POP clients and make
successful use of port 25 hard enough and rare enough, that
those who are already able to compromise machines to set up
those botnets won't figure out how to compromise IMAP or POP
clients, password stores, or legitimate posting traffic in order
to mimic those things to the degree needed.

regards,
   john

---

From: "Al Costanzo" <[email-masked]>
Date: Sun, 16 Aug 2009 13:47:15 -0500

But Ravi,

You may be rying to re-invent the wheel.  There is already PoP before Relay as well as other servers that require SMTP authentication requiring a user name and password to send.

These two items already do what you intend, however EVEN if you propose something else a virus will always cause a problem, no matter what you do.

I know since not only did I work on SMTP mail but also resell anti-viruii products.

I am sorry, I still cannot see the point of what you are trying to do since on the server side of the house you have SPF.  It is up to Mail Administrators to use these tools to stop spam.  If they use them, it works.  If you think they don't work, please explain.

Below, is some information for you if you did not read the SPF docs.

What is SPF?
SPF (defined in RFC 4408) validates the HELO domain and the MAIL FROM address given as part of the SMTP protocol (RFC 2821 - the "envelope" layer). The MAIL FROM address is usually displayed as "Return-Path" if you select the "Show all headers" option in your e-mail client. Domain owners publish records via DNS that describe their policy for which machines are authorized to use their domain in the HELO and MAIL FROM addresses, which are part of the SMTP protocol. 

What is Sender ID?
Sender ID (defined in RFC 4406) is a Microsoft protocol derived from SPF (hence the identical syntax), which validates one of the message's address header fields defined by RFC 2822. Which one it validates is selected according to an algorithm called PRA (Purported Responsible Address, RFC 4407). The algorithm aims to select the header field with the e-mail address "responsible" for sending the message. 

Since it was derived from SPF, Sender ID can also validate the MAIL FROM. But it defines the new PRA identity to validate, and defines new sender policy record tags that specify whether a policy covers MAIL FROM (called MFROM by Sender ID), PRA, or both. 

Which is better?
Neither is better because they address different problems. Comparing them is comparing apples and oranges. SPF can be compared to other SMTP layer protocol proposals like CSV/CSA. Sender ID can be compared to other RFC 2822 layer protocols like DomainKeys IM (DKIM). Nevertheless, the SPF technical community does have its own opinion on the merits of Sender ID.

Why is there controversy about SPF vs Sender ID?
The Sender ID specification contains a recommendation to use SPF's v=spf1 policies - which are originally defined to apply to MAIL FROM and HELO identities only - and apply them to the PRA identity as well. Specifically, it says to consider v=spf1 as equivalent to spf2.0/mfrom,pra. This is technically wrong, as is explained in detail below. Sender ID implementors should correct this and treat v=spf1 records as equivalent to spf2.0/mfrom. Unfortunately this mistake in the Sender ID specification was not corrected prior to its publication despite an appeal from the SPF project.

This creates a very bad situation in that Sender ID implementations that follow the recommendation in the Sender ID specification (RFC 4406, section 3.4) violate the SPF specification (RFC 4408). Since the Sender ID specification defers to the SPF specification for the definition of v=spf1, and because SPF has been in existence (prior to the publication as an IETF RFC) a lot longer than Sender ID, the recommendation in the Sender ID specification should be ignored by implementors.

Please explain why these dont work and I would be glad to help.

Regards,

Al Costanzo

IETF contributor/RFC Author since 1993 (and I still miss Jon Postel)

  ----- Original Message ----- 
  From: Ravi shankar 
  To: Philip Guenther 
  Cc: [email-masked] 
  Sent: Sunday, August 16, 2009 4:37 AM
  Subject: Re: Apps-Discuss Digest, Vol 19, Issue 6

  Philip,

  It's not the authentication mechanism that I'm proposing to change, but rather the method in which the mails are transsacted in today's setup.

  In the present setup, SMTP can be used by any computer connected to Internet to send mails directly to the server, resulting in spam which by normal means in indistinguishable from legitimate mails.

  What Botnets take advantage of is the fact that a normal Client computer (say, a home PC) can be infected to send spam. Instead if we classify, SMTP as the sole "Server to Server" protocol, it gives us the liberty to block those ports completely in the home/client computers.

  In order to allow the client computers that use POP3 and IMAP clients to continue transacting mails with SMTP blocked, we can extend them  to submit messages as well.

  While this way is not meant to protect against spam created by user name/password or identity theft, it is specifically aimed at controlling botnet spread spam, which accounts of 100 billion spam emails a day!.

  Regards,
  Ravi

  On Sun, Aug 16, 2009 at 3:50 AM, Philip Guenther <[email-masked]> wrote:

    Philip Guenther

    --
    Chief Architect
    Sendmail, Inc.

------------------------------------------------------------------------------

---

From: Tony Hansen <[email-masked]>
Date: Sun, 16 Aug 2009 16:28:55 -0400

Ravi, you're under the mistaken assumption that people should be using 
SMTP to send email. The current recommendations for message submission 
is to use the Message Submission protocol, which uses port 587 and is 
described in RFC 4409. While it is *based* on the SMTP protocol, it has 
various requirements that address all of your concerns. It's been around 
for about 11 years, but not ISPs have figured out that they should be 
requiring its use.

	Tony Hansen
	[email-masked]

Ravi shankar wrote:
> In the present setup, SMTP can be used by any computer connected to 
> Internet to send mails directly to the server, resulting in spam which 
> by normal means in indistinguishable from legitimate mails.
>  
> (say, a home PC) can be infected to send spam. Instead if we classify, 
> SMTP as the sole "Server to Server" protocol, it gives us the liberty to 
> block those ports completely in the home/client computers.
>  
> continue transacting mails with SMTP blocked, we can extend them  to 
> submit messages as well.
>  
> <[email-masked] <mailto:[email-masked]>> wrote:
> 
> ------------------------------------------------------------------------
>

---

From: "Al Costanzo" <[email-masked]>
Date: Sun, 16 Aug 2009 18:39:16 -0500

Tony,

I disagree.  RFC 4409 does not alter the use of port 25 in any way.  Some 
ISPs block port 25 and then use the ALT port 587 and use SMTP Auth.  But 
this is a waste of time with what this person wants to do.

All the ISP needs to do is turn on SMTP [SMTP-AUTH] on port 25 and the 
problem is solved.  it is also mentioned in the doc in section 3.3 (below so 
you dont have to grab a copy.  If you just turn on this feature, the problem 
is solved.  Most ISPs use this, my company does.

Regards,  -Al

----- Doc Inclusion -----

3.3.  Authorized Submission

   Numerous methods have been used to ensure that only authorized users
   are able to submit messages.  These methods include authenticated
   SMTP, IP address restrictions, secure IP and other tunnels, and prior
   POP authentication.

   Authenticated SMTP [SMTP-AUTH] has seen widespread deployment.  It
   allows the MSA to determine an authorization identity for the message
   submission, one that is not tied to other protocols.

   IP address restrictions are very widely implemented, but do not allow
   for travelers and similar situations, and can be easily spoofed
   unless all transport paths between the MUA and MSA are trustworthy.

----- Original Message ----- 
From: "Tony Hansen" <[email-masked]>
To: "Ravi shankar" <[email-masked]>
Cc: <[email-masked]>
Sent: Sunday, August 16, 2009 3:28 PM
Subject: Re: Apps-Discuss Digest, Vol 19, Issue 6

> SMTP to send email. The current recommendations for message submission is 
> to use the Message Submission protocol, which uses port 587 and is 
>> Internet to send mails directly to the server, resulting in spam which by 
>> normal means in indistinguishable from legitimate mails.

---

From: Alessandro Vesely <[email-masked]>
Date: Mon, 17 Aug 2009 09:24:56 +0400

> block those ports completely in the home/client computers.

Not straightforwardly. We'd need a way to distinguish a server 
from a client, for blocking client access.