Remote email access

Fri Jan 31 03:53:42 UTC 2003

At 10:25 PM 1/30/2003, Eliot Lear wrote:

>It's a rare day when I differ with Dave over mail standards, so 
>something's weird.
>
>Dave Crocker wrote:
>>Some current choices:
>>Email standards provide for posting of email to the usual port 25 or to
>>port 773 for the newer "submit" service. (Submit is a clone of SMTP that
>>operates on a different port and is permitted to evolve independently of
>>SMTP, in order to tailor posting by originators, differently from
>>server-to-server email relaying.) There is also a de facto standard for
>>doing SMTP over SSL on port 465, although this collides with the IANA
>>assignment of that port to another service.
>
>The submission port, according to IANA is 587.  I'm not a fan.  I also 
>think experience has shown that it is POSSIBLE to protect port 25 
>appropriately.  It's just a matter of doing it...
>
>See http://www.iana.org/assignments/port-numbers

I am a fan of port 587 being a viable alternative, as it provides a way for 
our customers who are blocked on port 25 to send their email through our 
servers (with SMTP AUTH or SMTP-after-POP). If this is going to be the norm 
from now on, it'd sure be nice if the MUAs had an automated way to set up 
users to use the SUBMISSION port. It'd also be nice if a certain large 
vendor fixed their MUA to understand STARTTLS and properly implemented it.

Port 25 blocking, especially on dialups, did for a time cut down on the 
spam levels. This benefit has largely disappeared as the spammers now use 
open proxies found all over the 'net.

>>Standardized SMTP authentication uses the SMTP Auth command or the SASL
>>service within SMTP. It can also use the de fact "POP hack". All 3 of
>>these mechanisms are inline -- as part of the posting protocol -- so
>>that they work over whatever port is being used for posting.
>>Standardized privacy for SMTP uses SMTP over SSL or it uses SMTP with
>>SASL.  SASL can be used on any SMTP or Submit port.  SSL can only be
>>used on port 25 if the SMTP service is not available to other SMTP
>>servers for relaying (or, really, for last-hop SMTP delivery).
>
>Although Dave is correct about SSL, RFC 3207 discusses the use of TLS for 
>purposes of encryption AND authentication.  I use this for my own 
>sendmail.  The biggest problem is ensuring that appropriate certificates 
>are installed.  Most of the common MUAs I tested have a way to do it, but 
>it's messy (to say the least).

We encourage our users to use STARTTLS, but they're using username/password 
for the SMTP AUTH (and the POP auth) rather than client certs.