Home smtp server with dynamic fusion service

[luoqi]

I've recently switched from AT&T to Fusion and I'm very happy with the service, but I've just noticed today that my home smtp server no longer receives any email which seemed to be caused by the blocking of port 25 traffic. Sonic.net tech support confirmed this when I called, but he said this firewall policy (blocking port 25 for dynamic DSL)was very unlikely to be changed. When I asked if it's possible to have mail.sonic.net act as a relay (by pointing my domain's MX to mail.sonic.net), he said nothing like this had ever been done and the best bet I have is to ask at the forum where the server admins are moderators. So here I am, technical I know this is doable (and not difficult:), but I wonder if sonic.net is willing to make this extra effort to help a customer. I would really appreciate this gesture.

Thanks
-luoqi

[dane]

We offer MX hosting with our DNS hosting service, this allows you to alias addresses under your domain to any destination, here or elsewhere. The cost is $1.95 per month.

I'll also say that in the not-too-distant future we anticipate offering single-IP static IPs at a very low cost, and this would also allow you to host your own mail server, w/o the usual port 25 blocking that exists on the dynamic IPs.

-Dane

[luoqi]

Thanks, it is indeed a welcoming news that single static IP will be offered, I guess it would be enough for most home and small business users. I'm sure would sign up once it's available.

I've a question on the firewall setting, this page (http://sonic.net/features/firewall/) has detailed explanations of the rules: port 25 restrictions are placed only on the inbound (customer->sonic) traffic, and on BOTH src and dst ports, wouldn't blocking only the dst port 25 on inbound traffic be sufficient to stop the spams and at the same time allow MTAs to function?

[dane]

The challenge is that compromised systems behave like an MTA, delivering spam directly. These zombie/bot-nets of compromised systems are the largest source of spam, so most service providers block port 25 outbound except for to their own mail servers for this reason.

-Dane

[luoqi]

Yes, it makes perfect sense to "block port 25 outbound except for to their own mail servers", but is it necessary to also block port 25 inbound from external mail servers to end-user systems? With outbound port 25 blocked, these systems can only receive spam, i.e., they can only be victims not vectors.

[dane]

Yes, this is a valid point, and I don't know the answer as to why it's bi-directional. I'll check with the team.

If it were outbound only, you could use us as an outbound smarthost for example - there are some reasons we may not want that, but it's one configuration.

Finally, all of that being said, single static IP for Fusion is coming, and may eliminate this as a concern.

-Dane

[luoqi]

I am using mail.sonic.net as a smarthost for outgoing mail and it works. For incoming, at this moment I have to employ a hack to first redirect to my company's MTA (which is also a sonic.net customer with a static IP block -- I am a loyal customer:) then relay to my home's MSA port (587). Hope this would hold long enough until single static IP comes out...

[dkurn]

[I posted this on the ACCESS list, but subsequently found the thread here. I've reposted my note; I hope I didn't break any rules]

Folks


Currently, sonic.net prevents both incoming and outgoing traffic on port 25. The reasons for this are probably:

OUTBOUND: Many spam-bots which infect the computers of unwary customers, send spam e-mails. These go out on port 25. Sonic is quite correct in preventing outbound port 25 from exiting their network, or working between computers inside sonic.net. I have no issue with this.

INBOUND: Sonic.net also prevents this. When queried about the reason, I got the explanation from Karen @ support:

This is to prevent "reflection" attacks which use the inbound port 25 to fool other servers into connecting to your server as they use their own server to send out the spam making it less taxing on their spamming server.

It took me a while to decypher this response. "Reflection attacks" (according to google) all involve a challenge-response protocol, but simple SMTP protocol on port 25 is not a challenge response protocol.

I therefore suggest that port 25 be opened inbound from the external network.

Anyone who has software listening to port 25 is probably not your "mom-and-pop Windows user". Setting up a mail server is a non-trivial thing. My Linux mail server, for example, was working for ten years on Comcast and ATT with lots of spam coming in, but various tools on my Linux box prevented damage.

The reason I want to run my own mail server is:
- I control what names are in use
- I control what domains I want to accept mail from, and also control the MX records that make it happen
- I don't want to use Sonic's mail server; it bothers me from a privacy perspective that my mail is stored on another computer, rather than "passes through".
- As a recent convert from ATT/DSL, they allowed port 25 inbound, and seemed to have no problems.

I know that Sonic.net will allow inbound port 25 to static IPs, but my IP is dynamic and has always been. Converting to a static IP could make Sonic.net non competitive in price.

I invite a discussion, because perhaps I haven't articulated my case properly, or may have forgotten some factor.

David (linux amateur in San Francisco, very happy with Sonic so far)
Guest dkurn

[epilog] If single fixed IP is available for 1.95/mo, I'd grab that too as a solution. WHEN? WHEN?

[dane]

Single-IP static is coming soon, at very low cost. I don't have specific response on the inbound vs. outbound port 25 blocking, others here may.

-Dane

[Soren]

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