Slashdot Mirror

Click here for sendmail 8.12.10 release notes

Also, a swedish CS student has posted an exploit on his web site. (With some code deliberately hobbled to prevent skript kiddies from abusing it)

The official announcement is here.

I've already downloaded and installed it. Thank goodness for Slackbuild scripts :)

This looks like it doesn't accomplish significantly more than the existing SMTP option STARTTLS.

There's a flag in sendmail FEATURE(`delay_checks').
This has some side effects that and you should consider reading the help page for delay_checks

With qmail, this behavior is the norm. Additionally, vrfy only returns a "252 send some mail, i'll try my best."
But I'm sure that most people turn off VFRY and EXPN in sendmail.

Obviously, you haven't heard of virtusertable...

The only solutions here are some sort of VPN to the network where my SMTP server lives (at work), or else ssh to the SMTP server (which is what I actually do, but it's inconvenient).

• Sendmail tips
• Qmail tips
• Exchange tips

If you're installing from CD, OpenBSD 3.3 did not contain sendmail 8.12.9. Correct me if I'm wrong but this was fixed in 3.3-current but didn't make it onto the CDs (?). Older sendmail-based servers should use patches 014, 027. See: www.sendmail.org/patchps.html

I too have noticed that the vast majority of spammers now seem to forge the HELO/EHLO greeting. And as most non-spammers don't, this is actually a wonderful way to catch them. I've even seen them send the IP address of my secondary mail gateway in hopes that my primary mail server would fully trust it (obtained probably by looking up my MX records). I run a mail gateway for a corporate domain an get on average 30 to 40 thousand spams per day. Using sendmail with it's milter programming interface I put the HELO greeting though a very strict check. For those contemplating doing the same...

• Per RFC 2821, the HELO greeting string should be either the FQDN of the sending hostname, or the IP address of the sending system in SMTP syntax (e.g., [1.2.3.4] or [IPV6:abcd::1234]
• Most spammers don't even bother with a domain name, using a random greeting like "sqss7e". If it doesn't have a domain, throw it away. Same if you see an IP address without the [] brackets; it's another dumb spammer that can't read the RFC's.
• Sometimes spammers don't even hide their spammy-sounding names in the HELO greeting even though they go to a lot of trouble to make up legitimate From headers. A good regular expression check for common words like "offers" or "optin" in the HELO greeting can work wonders (but use caution).
• When checking if a spammer if forging your own address, be sure to check for ALL hostnames under your domain (say you have acme.com, then check for both "acme.com" and "*.acme.com", and use a case-insensitive comparison). Also check for ALL your possible IP address even if you don't use them all. A remote site using your own IP or hostname is never legitimate.
• If you are running a gateway, you need to treat outbound versus inbound messages differently. This can usually be done by checking the connecting IP address to see if it is one of yours. Also be sure to check for 127.*.*.* and ::1 (IPv6).
• Be aware that some mail clients are broken and don't send conforming HELO greeting; this includes Mozilla (see Bug 68877). So don't be too agressive with your HELO checks for mail originating from the inside of your organization.

One last note about Forged AOL Spam after talking to one of their postmasters...all their legitimate mail by corporate policy is always sent from within the *.aol.com or *.aol.net domains. This will be in both the HELO as well as a reverse DNS lookup of the connecting IP address. If you don't see this in the HELO and DNS but you see a MAIL FROM for aol.com, it's probably spam.

I wish more big ISPs would provide public information about how to better detect forged mail claiming to come from their sites. For instance if I see a MAIL FROM *@yahoo.com, then should the connecting IP address always be from a *.yahoo.com host? Some ISP's like hotmail seemingly always add in a known predictable header whose absence indicates spam. But I can't reliably make these calls unless the ISPs provide that information. Also, beware that some semi-legitimate sites, like Monster.com forge the sending address on purpose; so if you want to receive resumes you may need to whitelist them.

If you are running a network, it behooves you to filter outgoing port 25. SMTP is a lousy protocol, and there is no successor to replace it (anytime soon).

E-mail server admins: Please lock down your servers! Only allow initial mail submission by authorized and authenticated clients, and only allow such subissions on a port other than 25. It's not that tough, and it's your job. Do it.

• Sendmail tips
• Qmail tips
• Exchange tips

There, no excuses.

U - user (authorization) id
I - authentication id
P - password
R - realm
M - list of mechanisms delimited by spaces
Or you could RTFM http://www.sendmail.org/m4/smtp_auth.html

http://www.sendmail.org/~ca/email/sm-812.html#812A UTH

you put this in your access map: "AuthInfo:smtp.server.of.your.isp "U:foo" "I:foo" "P:bar"" although you might need to know realms and/or mechanisms, too.

next time, at least check to see if it's an easy answer before you get belligerent and sarcastic.

"Excessively slow server detection will be a standard feature of all next generation spam software"

Let's hope so. Then I'd just accept all mail slowly and spam would go away!

Seriously there are flaws in this kind of defense. First, I'm already seeing several spammers who already send mail slowly, probably to avoid setting off statistical trappers and to make it harder to scan through log files. Also don't forget that the spammers usually have much more bandwidth than the recipient; you can never win by trying to fight the battle of resources!

BTW, this is NOT very tricky programming to do if you use the Milter programming interface to sendmail...in fact it is quite easy to do. But like I mentioned, you're sort of self defeating, because you burn your own resources by being slow.

If 50% of all mail in the US is spam, then the other 50% must be the bounces for all that undeliverable mail!

I run a mail gateway for a medium sized company, and although not on the scale of a large ISP, I see many of the same problems. Dealing with spam on a gateway level is quite different from dealing with a single personal mailbox. And spam flooding has gotten much worse in the last few months. Getting over a 1000 messages in under a minute can really start to tax your infrastructure. Actually from my own observations, I'd say that at least 75% of all mail is spam, and 80% of that is undeliverable.

Of course one of the big problems as Ramasubramanian points out is that spammers are getting very sophisticated at impersonating other entities. This results in a large number of bounces being directed back to the wrong guy. So not only are you getting spammed, but you are also indirectly spamming the poor guy who is being impersonated with your flood of bounces. And the bounces also cause other problems because it tends to fill up your outbound mail spools, as well as making the required postmaster account near useless sometimes.

One thing I've learned is that a mail administrator must be very careful about constructing blacklists and filters. I use sendmail and make heavy use of it's milter programatic filter interface. It's amazing how being able to analyze the mail at the protocol level (such as the HELO command) helps identify impersonated mail that can't just be done by only looking at mail headers or the message body. It is also possible to help correlate large volumes of nearly identical inbound mail from a large number of different servers, as well as correlate them with large number of undeliverable outbounds. I'm also very careful to check whois an other registrar databases before adding blacklist entries, to help prevent blacklisting the wrong guy. But I do admit that for a few of the most audacious flood attacks, I actually have to resort to iptables firewall blocks to stop it even before sendmail sees it. I really dislike having to disobey the SMTP standards, but spam floods are IMHO just as destructive as worms and viruses!

The thing I fear most as a mail administrator is not the inbound spam, but that some spammer may start impersonating my company! We'd start getting placed on blacklists and blocked, plus we'd start getting flooded with all those bounce messages (probably an order of magnitude more than direct spam). How can one possibly protect against that?

You chose the wrong example. Actually sendmail.org is pretty good at providing security patches for older versions of sendmail.
See this

When they talk about a "sendmail flaw", they are talking about sendmail versions 8.9 through 8.12, and perhaps older ones. They're not talking about mailers which are not sendmail, even if those mailers install a symlink called "sendmail".

By the way, does your perl script queue a mail for later retries if there's a temporary delivery failure? Or does it just throw the mail away?

Using the spammer's last SMTP protocol leg, before your mail server closes it, why not do the following:

By not letting go of the (would-be spammer's) SMTP connection, one can consult the mail recipient white list. From an unknown sender, instead, save the entire email in a holding queue and send back the following SMTP error message:

550 This is the first time you have contacted john@private-mailbox.net. To ensure that the email you have just sent reaches "john" and that you are not a spam robot, please send another email to the same email address with a Subject of "MD5-12312AFCD7654." Once done, you (i-am-not-a-spammer@goat.cx) will never get this message again from and "john" will finally get your email.

With a marriage of sendmail MILTER and Tagged Message Delivery Agent, one can shift the burden of automating the mail recipient white list back to the sender (like ICQ does).

With a tweak of the last leg of SMTP protocol, we, the email users, will have control over what is 200 and what is 5-f@cking-50.

What say you?

- Shamelessly ripped from the Seinfield TV episode "Soup Nazi."

Check the sendmail AUTH info, it discusses sendmail connecting as a client. There's also some info on STARTTLS that describes how to authenticate using TLS, but that would require more than just a password configuration on the other end (you'd need to get the remote sendmail to recognize your certificate as being allowed; I don't think there's any way to specify it on a per-user basis).

Check the sendmail AUTH info, it discusses sendmail connecting as a client. There's also some info on STARTTLS that describes how to authenticate using TLS, but that would require more than just a password configuration on the other end (you'd need to get the remote sendmail to recognize your certificate as being allowed; I don't think there's any way to specify it on a per-user basis).

I don't think a lot of readers are understanding the idea suggested in the original post. If you are an customer of a dialup ISP, use that ISP's SMTP server-- only. If you want to use someone else's SMTP server (including your own that you set up somewhere), then that SMTP server ought to be configured to accept initial mail submission on a port other than 25. Your "rank and file" customers will not have a problem with this-- they will continue to use the ISP's SMTP server and all is well. For those "power users" (define as you like) that have a need for external SMTP servers, well, have them do the work (sorry-- life sucks sometimes). The ISP posts a page explaining why port 25 is blocked, and suggests using alternate ports (e.g. 465, SMTPS).

If you are the admin of an SMTP server that external clients (i.e. unknown IP addresses) will connect to for intitial mail submission, you are doing the Internet (and your users) a disservice if such connections are allowed unauthenticated. Sendmail, QMail, Exchange (gasp!) all can be configured to require authentication for initial mail submission. Use SSL as well, and you will probably be using another port (465). Spammers are not going to port scan for a way to send mail! Admins-- get off your butts and secure your servers, or else you are part of the spam problem. Please don't gripe about how following industry standard practices for securing a publicly accessable server makes your job more difficult-- that is your job!

4) the best way you can take action is probably by taking one of the toy applications that are currently available for the 'free' os's and turn it into something real, it's a level playingfield out there.

apt-get also validates MD5 checksums before installing a package.

$ cat /usr/portage/net-mail/sendmail/files/digest-sendma il-8.12.6
MD5 73e18ea78b2386b774963c8472cbd309 sendmail.8.12.6.tar.gz 1867436

Like I said, SMTP AUTH is the way. It's available on near every mail server software in the world : Sendmail, Postfix, Exim, and even more. There is no need for an unsecured relay nowadays. Trust me.

What do I like best about Vexira?

Unpacks and extracts all MIME encoded messages without needing any other helper apps

Automatic updating

Very fast virus scanning

Reasonable price

We tested and evaluated vexira for about a month and it was clear that this app is a awesome antivirus.

Spam Assassin

Eudora Spam Filter

Mail Jail

Turn on your Sendmail antispam features!

Happy spamming, morons. I hope someone breaks your kneecaps. Repeatedly.

...but I still have to ban domains like yahoo.com, hotmail.com, mail.com

You can find out more about the ORDB here and this site has very simple instructions for setting up sendmail to use the ORDB filter. Sendmail.org has quite a bit of additional stuff you can do to filter SPAM and still let legitimate e-mail through. ORDB also has solutions for people who don't run their own mail server and just connect someplace with a mail client to get their mail.

If you run a sendmail server, you can block anyone / anything you want, and you can use some pretty strong authentication methods - strong enough to be sure you know who you're talking to.

Unfortunately, that's not the whole solution to the problem; while it works fine for businesses, it doesn't scale to large ISPs that have the moral fiber of two-dollar whores. Telestra is not alone in being willing to do anything for a couple bucks, and how would an ISP know who you want (or don't want) to talk to anyway?

As far as using full names goes, the Sendmail FAQ explains sufficiently well why that's a bad idea. See Q3.5.

Especially in a corporate environment, people expect to have reasonable looking user names. Most folks won't put up with being sfc123; it just is not professional.

This means that while it's a good idea to have guidelines, you can't be too much of a stickler. If a sales guy was jschmoe at his last three jobs, and all his contacts know his email as jschmoe, then it's really best if he can continue to be jschmoe. Forcing him to be joes341 instead doesn't make anyone happy.

Collisions are certainly an issue, but that's not the only problem. For example, a popular default choice might be first initial last name. Using that standard at one job we ended up with a "pharter" (say it out loud), and at another job there would have been an "aryan". These things just don't work.

Ideally I like to allow users their choice of login. I encourage them to select one of first initial last name, first name last initial, or initials. Every now and then someone will come along and want a login like "coolguy" or something completely random. Depending on the company culture and whether the user is "customer facing" I might be lenient.

I've worked in organizations up to a few thousand users and this system has worked fine. In a truly huge organization you'd end up having user names that look like AOL, though. Certainly in an educational environment I imagine a more authoritarian system would be warranted.

• MimeDefang
• OpenAntiVirus
• Spam Assasin
• Sendmail

But if these guys had never released their product with gaping security holes, we would never have discovered Outlook's security holes in the first place.

Step 2: Redirect traffic from your family domain to the dynamic one.

Step 3: Install Linux on a nice 486 with ~32 MB RAM and at least a 1 GB HD

Step 4: Install apache , sendmail, perl, and maybe webmin if you are completely unfamiliar with Linux.

Step 5: If you want a web front end for your email system, try out NeoMail

Step 6: That's about it, you'll have to mess with the configration files before it runs, but it's worth it. The fact that all your email is automagically downloaded to your local machine is just an added bonus.

Apparently, you aren't using Sendmail, or don't know anything about SMTP AUTH.

of course does SMTP have authentication ! see RFC 2554 ! it does solve your problem. really. use it. together with cram/digest-md5 auth.

Even most modern MTAs do support it, sendmail since version 8.10, postfix for sure, exim probably, and there is probably one of the bazillion patches for qmail that will solve this problem ;)

An open SMTP port is an entirely different thing from an open mail relay. The first means that a host will (probably) be able to recieve mail. The second means that the host will recieve mail and then send it off to another host. The mechanism you are proposing would prevent your host from receving mail from any host that could also recieve mail without discriminating between open relays and correctly configured mail servers.

The sendmail homepage has more info on how SMTP functions as well as how to block relay.

Nitpick, Sendmail has a large commercial side. And numerous companies have commercial offerings "below" (RedHat Linux) or "from" (commercial webservers based on Apache) a project that kick back varying degrees of support to the open source development.

I could see this being legit if, somehow, it prevented the SENDING of spam...

They are requiring the use of specific Microsoft mailers because they are the only ones which support certain SMTP AUTH mechanisms. LOGIN (a plaintext method) and NTLM are the most likely. A more complete list can be found here [sendmail.org]. They are almost certainly restricting outbound SMTP to their own servers.

They can't stop spam with this, but it does provide them with an audit trail. If one of their user's sends spam, they can determine with reasonable certainly which account it came from. It saves them the step of matching mail log entries with corresponding dialup log entries.

(The parent has not been modded high enough yet as of this post)

Regardless of the legal dispute, MAPS should have their implementation for filtering spammers removed from all MTAs. This is a frustrating problem, and is a major time-eater for diligent admins and an even bigger one for end-users on networks not overseen by such admins. Sendmail has removed MAPS support, reaffirming my commitment to stick with it since Sendmail's security record as been much improved over the past 3 years and it is great free software. A bitch to configure, but hey; when you run Slackware you know what you're getting into. I found it very alarming and frustrating when I decided to put a stop to what appears to be a significant increase in spam lately by finally getting around to implementing MAPS, only to discover the new fee-based implementation of MAPS. This pricing/policy change is completely antithetical to what anti-spam software should stand for! They started out as this "crusader" organization making software to rid the 'Net of the filth that proliferates as spam, then stick you with a fee? Quite unsamaritan and anti-community for a service that purports to assist the community, only to later suck you into payments once they've garnered enough of a following. Exploitative in the vilest sense.

ORDB is a godsend! I put this on my servers 2 days ago and spam has all but ceased. 10 trickled through the first day and were added to the list. ORDB's policy is effective, efficient and fair and it doesn't bog down the server or the network in any noticeable way. It's a quick 30 minute configure for a moderate sendmail admin, and yields immediate results. Granted it doesn't provide known spammer protections, but how can you do that?

The onus on stopping spammers is on ISPs through their AUPs. Once they make it crystal clear that using their network services for stupid things like Spam, port scanning, and defacing web-pages is going to immediately ban them from that service, the Spam and other useless 'Net activities will stop and these idiots will quietly go back to the middle-high school where they once worked and pick up their green weenies, Mr. Clean, and get those toilets clean and those hallway tiles shiny again, where their skills/socialization are most appropriate.

Clearly, we can't count on our Congress to improve the Spam sitation...

Today, I briefly considered how I could make so that when two of my machines happened to be exchanging mail with each other, they would do so through a crypto tunnel (at the transport level, not the message-body level), but after looking at the documentation, I realized that it would take me at least a week or two to get it working, if I'm lucky. And I just don't have the time.

The only way crypto is going to get used is if it's on by default.

We are so not there yet.

No, no, no.
If you want to go the "Sendmail is buggy" way, well, at least, try to be informative where the alternatives are concerned.

For those who wish to try another MTA, the three big ones, not counting Sendmail, are Exim (small and easy, good for your home net), Qmail, and Postfix (fast and powerful, my personal fav). All four have their good points, and all four are certainly worth checking before you decide on one.

See? I mean, if Sendmail is still so widely used, there is a reason, you know... :)

Perhaps this was a poor comparison, especially since the majority of email sends this way.

Just as with the GPL, you have to release the source, or else negotiate with the copyright holders when redistributing. The only added right is to redistribute closed source versions as long as you do so without charge. From the PoV of Microsoft's argument, it's hard to see how this can be less "anti-business" than the GPL is.

Wrong example Bill!
--

Use an MTA that supports the SMTP STARTTLS command, such as Sendmail or Exchange, and then configure it.

Use an MTA that supports the SMTP STARTTLS command, such as Sendmail or Exchange, and then configure it.

I've gone through this situation in several discussions for mid- and large-scale operations. Your answer will somewhat depend on how much money, time, and work you want to put into this system, with the usual tradeoff of ( more dollars ) = ( less ( time + effort ) ).

For a free solution, I've found that a sendmail-based solution works quite nicely on Solaris. We ran some internal mailservers with a combination of sendmail for smtp, qpopper for pop3, apache and php for web access, and ActiveState PerlMx for mail filtering. There are many passable imapd programs that would fulfill your IMAP requirement, among other things, cyrus imapd

Don't be fooled, though; this took some elbow grease, and a little tweaking with sendmail and qpopper (mostly for the remote-administration bit; you don't want all of your customers in /etc/passwd on your server!)

If you'd prefer to just lay down a little cash to get a working solution out the door, Openwave has a very reasonable email platform or two. It seems like it supports everything you're looking for, above.

Also, don't forget that Sendmail, Inc. creates some very sophisticated sendmail-based products; it looks like Advanced Message Server may have all of the solutions you're looking for.

1. Set up sendmail on your machine.
2. Create a spamdrop account.
3. Use that address in all correspondences with businesses, not a Hotmail address.
4. Forward that local address elsewhere, maybe back to your spamdrop Hotmail account.
5. Now you're sufficiently an "Email Service Provider."

...I am the Raxis.

youruserid+cowX@yourdomain.blah

The mail would get delivered to your box. If you start getting SPAM (Stupid People's Advertising Method) to "youruserid+cowX" or perhaps a "Dear Mr. YourUserid CowX" you will _immediately_ know where they got your address.

There are a number of features in sendmail to close open relays. check out the links below to get you started on it.

Allowing Controlled SMTP relaying in Sendmail 8.9
Relaying Denied/Allowed (in sendmail 8.8/8.9-8.11)

There are a number of features in sendmail to close open relays. check out the links below to get you started on it.

Allowing Controlled SMTP relaying in Sendmail 8.9
Relaying Denied/Allowed (in sendmail 8.8/8.9-8.11)

Also, pick up a copy of the bat book.

Fair enough, but if your car kept getting stolen, since you didn't lock it, left the engine running outside all the time, and perhaps put a big sign on it that said "steal me!", I wouldn't feel any sympathy for you. Furthermore, if you let it happen more than once (hell, theft of service happens hundreds of thousands of times with open relays) I'd simply point and laugh, for quite some time.

And yes, "it's not that hard, dumbass." There are several websites out there that teach people, in clear, concise steps, how to close an open mail relay, for both UNIX and NT; hell, for just about any operating system. People go to jail for leaving guns lying around when a kid picks one up and shoot someone. Why shouldn't people at least be scolded for running open mail relays when criminals use them to harass?

- A.P.

--
* CmdrTaco is an idiot.

You know you can do this yourself right? Setup a box that has an SSL/TLS enabled version of sendmail. Its supported in sendmail 8.11. It'll alow several methods of authenticating for mail relaying. From passwords to certificates. Once you have that setup, get sslwrap and wrap your pop/imap services. I've set this up for the company I work for. IE and Netscape support SSLwrapped Imap just fine. Same thing for pop. Fetchmail can be compiled to support this also. The SSL/TLS stuff is detailed here

Info on sslwrap can be found on freshmeat. Or you can apt-get it :)
Of course this all depends on your defintion of secure. It covers the authentication part in a layer of crypto, but it doesnt cover the SMTP relaying part. It can, but both servers need to support it. However in conjunction with gpg/pgp, it may be acceptable. Hope this helps.