[volunteers] Mailman and reverse DNS (encore)
rick at linuxmafia.com
Thu Dec 7 11:51:34 PST 2006
Quoting Paul Reiber (reiber at gmail.com):
> Rick - is our reverse DNS still fucked up & causing this?
> If so I'll call Brian/Joe and/or physically go there tomorrow.
> Please advise.
About what "caused this": You weren't specific about which "this"
you're asking about, but rather merely sent me an entire daily digest
from svlug at . In the future, would you mind please being more specific?
Since I'm going to go to some effort to scrutinise _all_ of the items
mentioned in your digest, I'm going to CC volunteers@, so our other
people can benefit from this rundown (if they're interested). I hope
you don't mind.
1. atexley at yahoo.com being removed:
Your mail doesn't include information about why this occurred. I could
probably dig into the Mailman logs to figure it out. Do you need me to
do that? (_You_ can also do that investigation, please note.)
2. Jobs post from blake.haggerty at sapphire.com requires approval:
jobs@ postings always require approval. (You probably weren't intending
to ask about that.)
3. todd at mrball.net subscription disabled for "excessive bounces":
Referenced attachment at
http://lists.svlug.org/archives/mailman-owner/attachments/20061207/2916b51b/attachment-0001.eml is from subscriber's MTA at mail.mrball.net, which
says the cause was "Sender IP address not resolving", and was marked as
a SMTP code 451, which was a temporary error, i.e., it would keep
Your guess is as good as mine concerning what mail.mrball.net meant when
it said "Sender IP address not resolving". For one thing, we don't know
what was in that MTA's tiny little mind when it said "sender": It could
have been referring to the originator of that message whose address was
in the "From:" header. That would be Robert Hajime Lanning
<lanning at lanning.cc>.
That is, mail.mrball.net might have an antispam regime that entails it
checking to make sure that domains used in "From:" headers are real,
which among other things would require making sure that the DNS
resolves. It would be reasonable to 451-temp-delay the mail while this
DNS check could not be completed because of a network condition that
might be transient.
Unfortunately (and I've explained this before, somewhat), Mailman's more
than a little stupid about what it considers a "bounce", as witness the
fact that 4xx-class soft (temporary) errors are counted as such, along
with 5xx-class permanent SMTP errors.
Or it could be considering svlug.svlug.org to be the "sender", which
impliedly would mean at mail.mrball.net could not resolve our forward
DNS. Our forward DNS remains extremely healthy. (I just
4. ravenderg at aol.com subscription disabled for "excessive bounces":
Referenced attachment at
is from subscriber's MTA at mailin-03.mx.aol.com, which says the cause
was "(DNS:NR) http://postmaster.info.aol.com/errors/421dnsnr.html", and
was marked as a SMTP code 421, which was a temporary error, i.e., it
would keep retrying.
Looking up the referenced page at
http://postmaster.info.aol.com/errors/421dnsnr.html , one sees that AOL
has a policy of requiring "that all connecting Mail Transfer Agents
have established reverse DNS" -- and that our MTA was found to have
none. They do not explain the reason for their policy, but it's almost
5. pcubbage at opencountry.com subscription disabled for "excessive bounces":
Referenced attachment at is from subscriber's MTA at mx5.aspextra.net,
which says the cause was "Client host rejected: cannot find your reverse
hostname, [188.8.131.52]", and was marked as a SMTP code 450, which was
a temporary error, i.e., it would keep retrying.
There is no reference to further information, but, honestly, how much
clearer could they be?
Also, honestly, did you really need me to interpret those SMTP error
messages for you? The only trick to them is knowing that 4xx errors are
temporary failures and 5xx ones are permanent failures. The rest is
just _reading the darned error text_. That's what it's there for.
Please read those error message texts in the SMTP DSNs (delivery status
notifications). Then, you probably won't have to ask me why the
"bounce" occurred, because it'll say right there.
And here's how you can check for yourself whether an IP has reverse DNS.
(This is repeat from my earlier explanation of the same thing.)
$ dig lists.svlug.org +short #First, do forward lookup to get the IP.
$ dig -x 184.108.40.206 +short #Now, do reverse.
It came up null. So, to answer your question, there's (still) no
I don't mind explaining these things once. I don't mind explaining them
twice. However, eventually I expect people will stop asking the exact
same questions, OK?
More information about the volunteers