Block port 25 (only) from all "open modem banks" (TM) to my SMTP servers.
If implemented on a large enough scale, the modem user will be
'encouraged' to use the SMTP server supplied with their account. Make each
dialup customer go through, and be authenticated by their own SMTP server.
I think I see an additional problem creeping in here.
The question is whether a dialup user should use the SMTP server of the
facility provider, or of the ISP that actually resells the account. You
could have virtual ISP resellers with no facilities at all, but lets take
a look at a small ISP that does have facilities, and is reselling dialup
to a national provider so his local business customers can have roaming
access without calling an 800 number.
If the small ISP opens their SMTP server to the IP addresses of the big
national dialup provider, which they would have to do in order to be able
to handle that roaming customer who could be just about anywhere, will
they not also be opening themselves up to being a relay for any spammer
that uses any reseller of that national provider? Will not such spammers
then have access to every ISP doing reselling via that national one?
I think the SMTP server that should be used when dialing that national
provider is the SMTP server provided by that national provider, unless
some kind of VPN is used (to be more technically correct, use the SMTP
server of the provider of IP addressing).
Roeland's issue still applies when the dialup customer is using his domain
name as the FROM/REPLY. But if the national provider SMTP servers accept
any domain name in the FROM/REPLY, and just log the reality as it sees it
in the header (e.g. dialup port and time which can be cross checked with
the access logs), then anyone can use these dialups, and spammers won't
get an advantage of being able to spew their filth to other than the SMTP
server of the dialup provider.
Port 25 restrictions don't solve the problem. The real solution is for
everyone to start leaning on their server vendors to deliver
authenticated SMTP. If you restrict relaying to only work with
authenticated connections, the problem goes away for the most part.
This solves another problem: mobile users. E.g., if I'm on the road
doing corporate mail, I want to connect to my corporate mail server
running encrypted SMTP. I certainly don't want my mail sitting on some
random ISPs mail hub.
I don't expect this to catch on in the client space in any major way
until the issue is forced by the servers denying relay services to
unauthenticated clients.
There are solutions available to this problem, the primary one being the
"smtp-after-pop" hack that is widely available and fairly widely used.
Essentially, issuing a STAT command opens up an SMTP relay window for
<admin-definable> minutes, whereupon if the user hasn't issued another STAT
in the mean time [e.g. they logged off] the "hole" goes away.
We were using that at my last job and it works just fine.
If the small ISP opens their SMTP server to the IP addresses of the big
national dialup provider, which they would have to do in order to be able
to handle that roaming customer who could be just about anywhere, will
they not also be opening themselves up to being a relay for any spammer
that uses any reseller of that national provider? Will not such spammers
then have access to every ISP doing reselling via that national one?
How about checking the MAIL FROM: part of the message? If a spammer tries to
use an invalid address, the small isp's sendmail can reject it outright.
I think the SMTP server that should be used when dialing that national
provider is the SMTP server provided by that national provider, unless
some kind of VPN is used (to be more technically correct, use the SMTP
server of the provider of IP addressing).
Yes, but how does the user know to change this? A redirection (some policy
routing and port fudging will help,) but it may be easier for the visp client
to be authenticated in some way, (like a radius scheme that picks up the
current remote ip address of the user and allows relay from that address
while the user is online.)