Um, you actually have to work somewhat to get sendmail to support unauthenticated submission on port 587. The default configuration is that port 25 is unauthenticated (albeit with some restrictions on relaying (only for local clients)) and port 587 is authenticated. As such, I'm not sure why you seem to think that sendmail on port 587 is unauthenticated. Sure, spammers will try anything that might work. However, for the moment, 587 is a reasonable pragma. Unauthenticated relays on 587 should definitely be blocked no questions asked. It's not that clear cut for 25. Owen --On Wednesday, February 16, 2005 2:36 +0000 Thor Lancelot Simon <tls@netbsd.org> wrote:
On Wed, Feb 16, 2005 at 02:23:04AM +0000, Adrian Chadd wrote:
Quite useful when it works (read: the other party has implemented AUTH-SMTP on port 587).
And if they's implemented unauthenticated SMTP on port 587, like, say, Sendmail, you've achieved nothing, or possibly worse, since you have encouraged people to simply run open relays on a different port than 25. How long do you think it's going to take for spammers to take advantage of this? (That's a rhetorical question: I already see spam engines trying to open port 587 connections in traces).
Slavishly changing ports isn't the solution. Actually using authentication is the solution. It is silly -- to say the least -- to confuse the benefits of the two.
Thor
-- If this message was not signed with gpg key 0FE2AA3D, it's probably a forgery.