ingress SMTP

Thu Sep 4 03:43:20 UTC 2008

If you leave port 587 un-authenticated then spammers just need to move their
spambots to try port 587 *and* you're never sure who sent the message.  If
you're going to have the customer click a few extra buttons to get to port
587, might as well get them to authenticate.

Authenticating port 587 is not the silver bullet, but it buys you a little
bit.

Frank

-----Original Message-----
From: Keith Medcalf [mailto:kmedcalf at dessus.com] 
Sent: Wednesday, September 03, 2008 7:34 PM
To: nanog at nanog.org
Subject: ingress SMTP

> On Wed, Sep 03, 2008 at 12:58:53PM -0400, Nicholas Suan wrote:
> > On Sep 3, 2008, at 12:49 PM, Jay R. Ashworth wrote:

> > >You're forgetting that 587 *is authenticated, always*.

> > I'm not sure how that makes much of a difference since the
> > usual spam vector is malware that has (almost) complete
> > control of the machine in the first place.

> Well, that depends on MUA design, of course, but it's just
> been pointed out to me that the RFC says MAY, not MUST.

> Oops.

> Does anyone bother to run an MSA on 587 and *not* require
> authentication?

Raises hand.

Why would the requirements for authentication be different depending on the
port used to connect to the MTA?

No matter how a session comes into the MTA (port 25, 465, 587, anything
else) and no matter whether it is encrypted or not, the requirement for
authentication (which is always available and advertized), is based on a
simple policy:

 - local delivery originating from a non-blacklisted or "internal/customer"
address does not require authentication;

 - relay from "internal/customer" IP Addresses does not require
authentication;

 - any connection from a blacklisted IP requires authentication or no mail
will be accepted;

 - relay from "external/non-customer" IP Addresses requires authentication;

Is there a valid reason why a different configuration is justified?

As an aside, outbound port 25 traffic is also blocked except from the MTA.