SMTP Relays...

From: Doc Shipley <>
Date: Thu Sep 2 16:56:07 2004

David V. Corbin wrote:

>>>>From: Doc Shipley []
>>>> You just defined most spammers, with respect to network
>>>>and MTA configuration. Add to that that a large percentage
>>>>of spam is relayed through compromised systems, and
>>>>blocking outgoing port 25 from a dynamic netblock is
>>>>reasonable. It *helps* the spam and Windows worm traffic a lot.
> Yes, it WILL decrease spam, but so would pulling the plug on the entire net.
> Seriously, look at the entire route a piece of spam takes and who it
> impacts.
> The generation of a large number of e-mails definitly impacts the people who
> RECEIVE them, the networks that CARRY them, the servers that GENERATE them.
> IMNSHO any of these people are quite within their rights (and even
> responsibilites)
> to block them.
> If my ISP had determined that the SMTP server at was being a
> bad boy, then let them blacklist that server.
> As I stated before, this policy (blocking outbound SMTP) does not impact the
> millions of people who are generating spam outside the ISP and ten clogging
> the ISP bandwith and my Inbox with spam. A polict of blocking both inbound
> and outbound traffic to specific IP addresses would address this also.
> Even setting a default of blocking all port 25 access would be reasonable IF
> THEY WERE WILLING TO OPEN SPECIFIC IP's upon reciept of a document
> validiting the need for the access.

   I'd like this too. Doesn't look like it'll happen, ever.

>>>>accounts, and none need any secondary configuration. Our
>>>>relayed SMTP uses SSL/TLS and SMTP AUTH on ports 465 and
>>>>587. Nobody blocks those ports, nor are they likely to ever do so.
> True, but what would you do IF your ISP decided do block those ports (maybe
> they just don't like the numbers). Consider the impact on you (especially
> from a support point) if tomorrow morning ALL of your clients started
> reporting that they could not send e-amil and were blaming you [especially
> until you figured out WHAT was happenin!].

   No ISP is likely to block encrypted/authenticated ports, simply
because a mailserver listening to those ports is very probably hardened.

   It seems to me that your issue here is personal, and stems much more
from the total lack of warning by opton, which *was* entirely negligent,
than the actual policy of blocking port 25.

   The final argument here is that if we wanted to run *real* mail
servers, we'd have "real" connectivity, i.e. colocated hardware. As
long as we're going with the much cheaper ISP route, we're at the mercy
of the ISP's [often uninformed] whim.

Received on Thu Sep 02 2004 - 16:56:07 BST

This archive was generated by hypermail 2.3.0 : Fri Oct 10 2014 - 23:37:27 BST