|
|
The content of this page was last updated on 2003/03/08 06:53:27. I'm no longer maintaining it, but it seems still to be relevant.
Sometimes people have trouble sending mail to us. The perception is frequently that this is a problem at LEMIS. While that's not impossible, it's highly unlikely. For the past fifteen years, there has been no time when our mail system has been down for anywhere close to the standard five-day delivery period; the longest outages have been about two days, caused by serious cable breakage in the Telstra network.
So why can't you send us mail? There are a number of reasons. This page will help you find out which applies to you.
LEMIS receives a lot of mail. A large proportion of it is spam, unsolicited commercial Email. LEMIS takes drastic steps towards reducing the amount of spam. Much spam is clearly criminal: it forges addresses. Favourites are hotmail.com and yahoo.com. Clearly we can't block these addresses, though we do block some large ISPs with inadequate abuse prevention; see below.
One thing is clear, though: if I get mail from, say, yahoo.com, I can expect the sending Mail Transfer Agent (MTA), sometimes called the mail (SMTP) server, to be located at yahoo.com. That would be an easy thing to check, if I could find the name of the server. The SMTP protocol provides for the server to state its name when delivering a message. The exchange looks something like this:
Out: 220 wantadilla.lemis.com ESMTP Postfix In: HELO mx3.mail.yahoo.com Out: 250 wantadilla.lemis.com In: MAIL From: <cn@yahoo.com> Out: 250 Ok In: RCPT To:<grog@lemis.com> Out: 250 Ok In: DATA
This format is what shows up in the error messages from Postfix, the MTA which I use. Lines starting with In: are from the sending MTA, lines starting with Out: are from my MTA. In this exchange,
There's something suspicious about this message, though. Yahoo!'s MTAs do understand ESMTP; in fact, just about all non-toy MTAs do. In reality, this is really a touched up version of an example rejected by my MTA. The real message looks like this:
Out: 220 wantadilla.lemis.com ESMTP Postfix In: HELO mx3.mail.yahoo.com Out: 250 wantadilla.lemis.com In: MAIL From: <cn@verizon.net> Out: 250 Ok In: RCPT To:<sinfullweb@yahoo.com> Out: 450 Client host rejected: cannot find your hostname, [66.157.194.5] In: RSET Out: 250 Ok In: QUIT Out: 221 Bye No message was collected successfully.
It's very unlikely that Yahoo! will send mail originating from verizon.net. Much more interesting, though, is the line
Out: 450 Client host rejected: cannot find your hostname, [66.157.194.5]
66.157.194.5 is the IP address of the remote MTA. You can use DNS reverse lookup to find the name based on the IP address; or you should be able to, but in this case it didn't work. Why not?
If this is spam (and the faked From: address strongly suggests that it is), then the last thing the sender wants is for us to find the real name, so he deliberately disables reverse lookup.
There's a way to get an idea, though: use traceroute, a test program which finds the route from where you are to a remote destination. In this example, the trace finishes like this:
20 195.ATM6-0.GW5.JAX1.ALTER.NET (152.63.84.225) 403.109 ms 403.126 ms 413.466 ms 21 bellsouth-gw.customer.alter.net (65.195.232.214) 419.779 ms 408.751 ms 413.318 ms 22 205.152.187.141 (205.152.187.141) 414.288 ms 413.755 ms 409.784 ms 23 host-205-152-78-38.jax.bellsouth.net (205.152.64.38) 433.995 ms 421.272 ms 412.142 ms 24 205.152.90.198 (205.152.90.198) 413.996 ms 413.329 ms 737.806 ms 25 205.152.105.78 (205.152.105.78) 409.310 ms 411.183 ms 414.458 ms 26 * * *
The * * * at the end suggest that the machine isn't connected. Long before that, though, it's clear that this site is in the bellsouth.net network. We get there from alter.net, but it's not their fault. Clearly this is spam.
There's another possibility, of course: maybe it's you, and you want to send a legitimate E-Mail, but your DNS is broken. Sorry, we can't distinguish between this and real spam, except by the sender address. I regularly check the error log and send messages to people whose mail address I recognize. Here's a case in point:
Subject: Postfix SMTP server: errors from unknown[12.235.52.250] Transcript of session follows. Out: 220 wantadilla.lemis.com ESMTP Postfix In: EHLO panda.mostang.com Out: 250-wantadilla.lemis.com Out: 250-PIPELINING Out: 250-SIZE 10240000 Out: 250-ETRN Out: 250 8BITMIME In: MAIL From:<sane-devel-admin@mostang.com> SIZE=1932 Out: 250 Ok In: RCPT To:<grog@lemis.com> Out: 450 Client host rejected: cannot find your hostname, [12.235.52.250] In: RSET Out: 250 Ok In: QUIT Out: 221 Bye No message was collected successfully.
This message came from a mailing list to which I am subscribed. For some reason, they had transient DNS problems. If I could find an easy way of distinguishing this kind of rejection from the previous one, I would, but in this case things are made worse by the fact that the MTA server panda.mostang.com is valid, but it has a different IP address. In cases like this, I pipe the message through a script which replies to the postmaster and the sender:
The attached message is caused by a misconfiguration of your DNS server: your mail server 12.235.52.250 does not have reverse mapping. In addition, it claims to be panda.mostang.com, which has a different IP address (24.250.133.228). As an anti-spam measure, we require reverse lookups for all mail we accept. This message will not be delivered unless you correct your DNS configuration. Since this situation has continued for a considerable period of time, we must assume that it is not a transient problem. If you believe this assessment is incorrect, or if you need help resolving the problem, please contact me by phone at +61-8-8388-8286 between 9 am and 6 pm Central Australian time (currently GMT+1030). ******************************************************************* sane-devel-admin@mostang.com, you have been copied on this message because we have reasonable grounds to believe that you are not aware of these problems, and that you have entrusted mostang.com to deliver your mail for you. This message is an indication that mostang.com is not perfoming this task correctly. If the situation continues, you should contact mostang.com support and get them to rectify the problem.
Some other common configuration errors can prevent mail being delivered as well:
Subject: Postfix SMTP server: errors from smtpout.ev1.net[207.218.192.47] Transcript of session follows. Out: 220 echunga.lemis.com ESMTP Postfix In: EHLO smtp3.ev1.net Out: 250-echunga.lemis.com Out: 250-PIPELINING Out: 250-SIZE 10240000 Out: 250-ETRN Out: 250 8BITMIME In: MAIL FROM:<octopus@ev1.net> Out: 250 Ok In: RCPT To:<irish@dunham.org> Out: 450 <smtp3.ev1.net>: Helo command rejected: Host not found In: QUIT Out: 221 Bye No message was collected successfully.
In this case, the MTA has reverse mapping, but the name specified on the EHLO line is not registered. Yes, if you look at the Subject: line, you'll see that the name does reverse map, but the name is smtpout.ev1.net, not smtp.ev1.net. Humans can recognize that this is probably just a minor configuration error, but Postfix can't. It's just sloppy system management, but the people at ev1.net don't seem to care.
Subject: Postfix SMTP server: errors from dup-148-233-224-49.prodigy.net.mx[148.233.224.49] Transcript of session follows. Out: 220 echunga.lemis.com ESMTP Postfix In: EHLO 148.233.224.49 Out: 250-echunga.lemis.com Out: 250-PIPELINING Out: 250-SIZE 10240000 Out: 250-ETRN Out: 250 8BITMIME In: MAIL From:<monzone5935@eudoramail.com> SIZE=4276 Out: 250 Ok In: RCPT To:<webmaster@freebie.lemis.com> Out: 450 <148.233.224.49>: Helo command rejected: Host not found In: QUIT Out: 221 Bye No message was collected successfully.
In this case, the MTA is incorrectly configured: EHLO should specify a name, not an IP address.
Not all spam can be rejected so easily, of course. A number of hard-core spammers have perfectly functioning DNS, but all we ever get from them is spam. Postfix has a means of rejecting spam from specific addresses. Here's an example:
Subject: Postfix SMTP server: errors from sparc20.guomai.sh.cn[202.96.206.74] Transcript of session follows. Out: 220 wantadilla.lemis.com ESMTP Postfix In: EHLO sparc20.guomai.sh.cn. Out: 250-wantadilla.lemis.com Out: 250-PIPELINING Out: 250-SIZE 10240000 Out: 250-ETRN Out: 250 8BITMIME In: MAIL From:<bill4h56@china.com> SIZE=1348 Out: 250 Ok In: RCPT To:<grog@wantadilla.lemis.com> Out: 550 <bill4h56@china.com>: Sender address rejected: " Mail rejected. See http://www.lemis.com/dontspam.html" In: RSET Out: 250 Ok In: QUIT Out: 221 Bye No message was collected successfully.
In this case, we have blocked the entire china.com domain, since we have never had anything but spam from them. If you're a user at china.com, you will be blocked too.
As the reference to http://www.lemis.com/dontspam.html will show, we can enable access for you in such a case; just find a way to contact us. If, of course, you abuse this feature to send spam, you'll be blocked for ever.
We block other domains, too. Currently, we have blocked home.com. We got a lot of spam from them, and there was no way to report it: send a spam message to abuse@home.com and it will be returned unread because it is spam:
Date: Tue, 14 Aug 2001 18:51:51 -0700 (PDT) From: Mail Delivery Subsystem <MAILER-DAEMON@mx4-rwc.mail.home.com> To: <grog@lemis.com> This is a MIME-encapsulated message --f7F1pp001424.997840311/mx4-rwc.mail.home.com The original message was received at Tue, 14 Aug 2001 18:51:50 -0700 (PDT) from wantadilla.lemis.com [192.109.197.80] ----- The following addresses had permanent fatal errors ----- <abuse@home.com> (reason: 553 Spam not welcome here... (c-to)) ----- Transcript of session follows ----- ... while talking to mh4-sfba.mail.home.com.: >>> DATA <<< 553 Spam not welcome here... (c-to) 554 5.0.0 <abuse@home.com>... Service unavailable
If you're a home.com user, I'd strongly recommend getting a reputable ISP. If that's not possible, contact me and I'll make an exception to the block.
In some cases, even the repeated attempts to deliver become a nuisance. Some MTAs retry every minute. That results in 1440 reject messages per day for me to plough through. Alternatively, forged headers make it impractical to block based on the sender name, because it changes every time. In such cases, I'll put a firewall block on the IP address range. I don't know how big the address range is, so I'm guessing it's the size of a class C network (256 addresses). Foe example, I recently received spam from 202.110.48.9, so I blocked the address range 202.110.48.0/24:
ipfw add 6000 unreach port log tcp from 202.110.48.0/24 to any setup
Again, there's a chance of collateral damage. If you're affected, please contact me.
Of course, the fact that we haven't had a serious outage in fourteen years doesn't mean that there won't be one in the future. If you think we're down, try pinging. We don't disable ping, so if you can't ping mx1.lemis.com, then either we're down, or the network is. Have patience, it shouldn't take more than a day or two.
Greg's home page | Greg's diary | Greg's photos | Copyright |