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@dessus.com] Sent: Wednesday, September 03, 2008 7:34 PM To: nanog@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.