SMTP outbound best practices
-
I have a open wifi subnet / adapter.
I have some allow rules so people actually can do something on this network :)
I am using the following rule set to allow basic access to e-mail, web etc.
The down side is that they can receive mail and use programs like outlook (which is fine) but they are also able to SEND e-mail (spam) using a postfix server.
What would be the best way to allow sending/receiving mail through their e-mail programs but disallow outbound mail spam? I guess I would need level 3 software to do this?
Or should I just go ahead and disable smtp access alltogether (so they can only use http/https?)PS: I tried disabling all rules except port 80 hoping all traffic would go through my transparant proxy but then internet doesn't work (port 53 is being blocked). Why doesn't all traffic go through the proxy in this case including smtp/dns traffic?
-
Block outbound 25, almost all mail systems now will let clients use authenticated smtp submission over port 587 or smtps on port 465, mail clients shouldn't be using 25 directly anymore.
For the second q, DNS does not get proxied, that still goes to the client's DNS server. If you're in transparent mode, the client doesn't know the proxy exists, and 53 doesn't get redirected, it still needs to reach the DNS server.
-
The decision to totally block port 25 may or may not be acceptable, depending on your audience. The way I prefer to deal with this issue is via throttling such traffic. Unfortunately pfSense doesn't offer much flexibility to configure this via its webGUI, although the underlying PF is quite capable to do so.
Check my previous post http://forum.pfsense.org/index.php/topic,41679.0.html and related feature request http://redmine.pfsense.org/issues/1935
-
Several major ISPs have been blocking outbound 25 for a long time now. If your mail server is local, only let it out on 25, block everyone else. If your mail server is remote, you should really be using some form of authentication and encryption on your outbound mail.
In the cases where you cannot, you can still restrict on the destination rather than the source, just lock it down to your remote mail server IPs.
-
jimp, I agree with your suggestion, but keep in mind that one can do STARTTLS on port 25, as well as on 587.
I know that some ISPs in certain countries do block port 25, but in my experience many ISPs in Europe don't and if you do block port 25 in a setup like the OP's, you will frustrate a lot of people and you should be prepared to handle a lot of support calls …
-
Just because you can do TLS there doesn't mean you should. :-)
If you have no control over the users then it does make it much harder to filter, but even when Verizon started blocking it, people just got over it and moved on.
