by Soren » Thu Apr 26, 2012 10:02 am
I know many Sonic customers know how to set up a mail server, but that doesn't mean they are going to set it up correctly (see below). Hopefully must of us would know not to be an "open relay," but some of us would get it wrong and spammers would take advantage. I suspect the "reflection attacks" are when spammer system S gets customer system C to forward mail to ISP's relay R. The relay trusts C more than it would S because C is on ISP's network ... and off you go. "Mom and Pop's Windows box" doesn't come *configured* to run an SMTP server on port 25, but once it is part of the bot net, you can be sure that it will be listening on all kinds of ports to accept spam messages to relay through the ISP's relay. If blocking port 25 makes it harder for the spammers to do this, it seems like a good tradeoff *for dynamic IP customers* (including me).
I came across this thread while configuring command-line mail with smtp.sonic.net and suspect that the above "allow relaying from inside your network" trust example above will come down to a trade-off between me being able to run
$ echo message | mail
foo@gmail.com
without having to store my Sonic password in the postfix configuration files (to authenticate to smtp.sonic.net) and blocking inbound port 25 to dynamic IP addresses.
In an age of spam, running a mail server requires constant vigilance and at least a $1.95/mo commitment (the DNS hosting cost) or a static IP so that Sonic can call you if your server is screwing up. As an example of the complexities, I had never thought about how mail forwarding affects "spam reputation." Yet lots of users forwarding *all* their mail off a server I help administer meant they were forwarding a ton of spam and thus our host was being counted as a source of spam and thus real messages were sometimes rejected. :(
-Soren