$whoname
Problems sending mail to LEMIS
Greg's diary
Photo index
Greg's home page
Network link stats
Greg's other links
Copyright information
Groogle
by Greg Lehey
Last update: $Date: 2011/09/28 04:16:46 $

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.

Incorrect configuration at your end.

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,

  1. My MTA announces its name, and that it understands ESMTP, the Extended Simple Mail Transfer Protocol.
  2. The remote MTA claims that it is mx3.mail.yahoo.com. The text HELO indicates that it only understands SMTP, and not ESMTP (otherwise it would reply with EHLO instead).
  3. The local MTA then replies with its name in SMTP convention.
  4. The remote MTA then states the name of the sender.
  5. The local MTA accepts it.
  6. The remote MTA then states the name of the recipient.
  7. The local MTA accepts it.
  8. The remote MTA states that what follows is the message.

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.

You may have been blocked.

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.

Firewalling

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.

Maybe it's a LEMIS problem after all.

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

Valid XHTML 1.0!

$Id: lemismail.php,v 1.7 2011/09/28 04:16:46 grog Exp $