I want to discuss the following SMTP error message:
-----------------
These recipients of your message have been processed by the mail
server: mun...@munged.com; Failed; 5.4.0 (other or undefined
network or routing status)
Reporting-MTA: dns; (a server in Germany)
Arrival-Date: Fri, 5 Oct 2007 15:09:32 +0200
Final-Recipient: rfc822; mun...@munged.com
Action: Failed
Status: 5.4.0 (other or undefined network or routing status)"
-------------------
--
Kenneth Murchison
Systems Programmer
Project Cyrus Developer/Maintainer
Carnegie Mellon University
Is that a mailing list? If so, is there a web interface?
Are there any active *.ietf.* newsgroups?
I only speak for my self, but isn't SMTP fairly on-topic here, in
comp.mail.headers? Compare with comp.protocols.tcp-ip, which gets
(and tolerates) a lot of questions on socket programming, HTTP and other
semi-related things.
> I want to discuss the following SMTP error message:
>
> -----------------
> These recipients of your message have been processed by the mail
> server: mun...@munged.com; Failed; 5.4.0 (other or undefined
> network or routing status)
>
> Reporting-MTA: dns; (a server in Germany)
> Arrival-Date: Fri, 5 Oct 2007 15:09:32 +0200
>
> Final-Recipient: rfc822; mun...@munged.com
> Action: Failed
> Status: 5.4.0 (other or undefined network or routing status)"
> -------------------
Is there much to say about it? 5.4.0 is the only information you have
(you can look up its meaning; if it is worth trying again later and so
on). The text just says this is an "other" failure.
/Jorgen
--
// Jorgen Grahn <grahn@ Ph'nglui mglw'nafh Cthulhu
\X/ snipabacken.dyndns.org> R'lyeh wgah'nagl fhtagn!
> I only speak for my self, but isn't SMTP fairly on-topic here,
> in comp.mail.headers?
> > I want to discuss the following SMTP error message:
> Is there much to say about it? 5.4.0 is the only information
> you have (you can look up its meaning; if it is worth trying
> again later and so on). The text just says this is an "other"
> failure.
Ok, here's what I want to talk about with respect to error 5.4.0. You
will see how my question relates to SMTP in general.
For the past 2 years, I've been running our mail server without an MX
record. This originally happened when we moved our office and changed
ISP's. The missing MX record wasn't noticed for a few months -
because our A record pointed to the same IP as our MX record would
have if it was configured.
I have left our MX record in that (null) state because what did happen
was an immediate reduction in spam - I would guess 75% right off the
bat, and basically no growth in spam ever since. (I'm talking about
zombie-spam).
At the time, it seemed that the explanation was that a sending MTA
would fall back to a domain's A record upon an MX-lookup failure. We
encountered no external hosts (or people) who claimed they were
getting errors trying to send us e-mail. We are in touch with a
diverse set of educational and biomedical entities all over the world,
and we were able to maintain e-mail contact with them.
I recently became aware of a case where the lack of an MX record has
prevented proper communication.
Here is the error message as seen by the sender:
----------------
These recipients of your message have been processed by the mail
server: mun...@munged.com; Failed; 5.4.0 (other or undefined
network or routing status)
Reporting-MTA: dns; (a server in Germany)
Arrival-Date: Fri, 5 Oct 2007 15:09:32 +0200
Final-Recipient: rfc822; mun...@munged.com
Action: Failed
Status: 5.4.0 (other or undefined network or routing status)"
-------------------
I'm wondering why the error wasn't 450 (or 4.5.0 ???) instead of
5.4.0.
I'm also wondering if I should engage the postmaster of the sending
MTA and ask him why his server is not falling back to the A record.
Our organization really enjoys the very low spam load we currently
receive, and I would hate to activate our MX record without some idea
that we perhaps are missing quite a lot of incoming e-mail.
Comments?
> Ok, here's what I want to talk about with respect to error 5.4.0. You
> will see how my question relates to SMTP in general.
>
> For the past 2 years, I've been running our mail server without an MX
> record. This originally happened when we moved our office and changed
> ISP's. The missing MX record wasn't noticed for a few months -
> because our A record pointed to the same IP as our MX record would
> have if it was configured.
>
> I have left our MX record in that (null) state because what did happen
> was an immediate reduction in spam - I would guess 75% right off the
> bat, and basically no growth in spam ever since. (I'm talking about
> zombie-spam).
>
> At the time, it seemed that the explanation was that a sending MTA
> would fall back to a domain's A record upon an MX-lookup failure. We
That's a requirement of the protocol, so I sure hope they do. MX
records are used as a way to redirect mail to some *other* server, but
the default is to send mail to the host specified in the address.
> encountered no external hosts (or people) who claimed they were
> getting errors trying to send us e-mail. We are in touch with a
> diverse set of educational and biomedical entities all over the world,
> and we were able to maintain e-mail contact with them.
>
> I recently became aware of a case where the lack of an MX record has
> prevented proper communication.
>
> Here is the error message as seen by the sender:
>
> ----------------
> These recipients of your message have been processed by the mail
> server: mun...@munged.com; Failed; 5.4.0 (other or undefined
> network or routing status)
>
> Reporting-MTA: dns; (a server in Germany)
> Arrival-Date: Fri, 5 Oct 2007 15:09:32 +0200
>
> Final-Recipient: rfc822; mun...@munged.com
> Action: Failed
> Status: 5.4.0 (other or undefined network or routing status)"
> -------------------
>
> I'm wondering why the error wasn't 450 (or 4.5.0 ???) instead of
> 5.4.0.
See RFC 1893 on Enhanced Mail System Status Codes.
>
> I'm also wondering if I should engage the postmaster of the sending
> MTA and ask him why his server is not falling back to the A record.
You don't know for sure that this is the reason. Maybe it really is a
network routing problem.
--
Barry Margolin, bar...@alum.mit.edu
Arlington, MA
*** PLEASE post questions in newsgroups, not directly to me ***
*** PLEASE don't copy me on replies, I'll read them in the group ***
Yes.
> If so, is there a web interface?