Anti-spam methods (was: Re: Comcast blocking port 25? (not what
pri.lugofnh at iadonisi.to
Mon May 10 14:21:01 EDT 2004
On Mon, 2004-05-10 at 11:44, Bob Bell wrote:
> However, recently I was reading about SPF and discovered MSA. Although
> MSA may optionally do more sophisticated things, in a limited format you
> can run a "normal" SMTP server implementing authentication on the MSA
> port (TCP port 587), and non-MSA aware programs like Outlook can use it
> as long as they implement SMTP authentication and can be redirected to
> a different port. ISPs typically don't block port 587 because (1) MSA
> is new and they probably may not be aware of it, and (2) MSA requires
> authentication, which probably eliminates the reasons they may have for
> blocking outbound port 25. To turn on MSA in sendmail, I simply
> commented out the "no_default_msa" in my sendmail.mc file. (Actually,
> for reasons unnecessary to get into here, I added the equivalent line "O
> DaemonPortOptions=Port=587, Name=MSA, M=E" to sendmail.cf directly).
I was going to bring up MSA, too. It should be noted, however, that
MSA doesn't *require* authentication. Check out RFC 2476 for details.
The RFC does lists authentication as an optional feature, however. I
*think* the DaemonPortOptions line above will not require the
authentication you mention. You need to specify 'M=Ea' instead of just
'M=E'. That's for sendmail...your MTA may vary.
I recently posted a message to the SPF mailing list referring to the
problem of spam cannon infected computers on broadband lines. I'm
basically on the side of individual freedoms and don't like that port 25
egress filtering is being implemented by broadband vendors. But as long
as there are vendors that will give you an unfiltered connection (even
for a larger fee), with fixed IPs, I'll be happy. I wouldn't be opposed
to vendors allowing this only if you host your own domains and email
servers and point something at your fixed IPs so that you get the
freedom, but with the attendant responsibilities. (Yes, I know that
info is often faked, but that's a separate problem.)
I do predict that spammers will adapt to this new authenticated email
world rather quickly. Namely, they will modify their spam-cannon-laden
viruses to pick up the user's SMTP server and username from his Outbreak
config and either pick up the password from the config if it's saved, or
sniff it as it's typed. With this information, they can continue to
send spam *to appear as if it came from this user in every way*,
including being sent through his ISP's SMTP server, and therefore bypass
many spam filter that are based on blacklists or forged headers.
But we will still be in a better place when it comes to spam. When
enough clueless users get disconnected from their ISPs for spam
propagation, they will either take more proactive measures to keep their
systems clean of viruses, or put more pressure on their operating system
vendors of choice to put security where it belongs: at a much higher
priority than convenience. Or both.
I don't much like many of the methods people are using or advocating
for spam filtering. I particularly dislike *anything* that does
uniform, system-wide filtering that *discards* any messages whatsoever.
If it's not configured on a per user basis, then *rejection* and
*bouncing* are the only acceptable options, in my view. And bouncing is
usually ineffective, given the amount of forging of headers going on.
So if you can't reject, then at the system level about all you should do
is filter into the users' SPAM or JUNK or whatever folders. Never
For the OP, I'd suggesting setting up an MSA, but if you plan on using
TLS/SSL (recommended) you'll need to use 'M=Eas' instead of just 'M=Ea'
(for sendmail). Run it on port 465 (smtps) so you can leave 587
(submission) for the typical 'M=Ea'. This is because our favorite MUA
of all doesn't support STARTTLS on any port besides 25...it just goes
straight to an encrypted connection instead of doing the STARTTLS
negotiation. Have your parents change their port setting to 465, enable
TLS/SSL, and enter a username/password pair that you create for them as
SASL ids on your server.
Sadly, I'd suggest that we all get used to this up and coming
authenticated email world. In and of itself, it's not going to reduce
spam...but it will potentially make it easier to identify the scum and
use other, ahem, non-technical means to pursue them. Like cutting off
their ... um ... well ... okay, not that, but at least cutting off their
connections and using other means like jail time, seriously big LARTs,
not inviting them to parties, etc, etc. ;-)
Senior System Administrator
Red Hat Certified Engineer / Local Linux Lobbyist
Ever see a penguin fly? -- Try Linux.
GPL all the way: Sell services, don't lease secrets
More information about the gnhlug-discuss