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 discard. *sigh* 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. ;-) -- -Paul Iadonisi 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 _______________________________________________ gnhlug-discuss mailing list [EMAIL PROTECTED] http://mail.gnhlug.org/mailman/listinfo/gnhlug-discuss
