[TAG] Message sending failure

[Rick Moen]

Quoting Martin Hooper (martinjh at blueyonder.co.uk):

> Any reason this might have happened?  Not sure whether it could be a 
> problem at my ISP or at the other end..?
> 
> If it could be my ISP then I'll mention on their support groups.

Cutting to the chase and answering your question, the "reject" DSN
(Delivery Status Notification) you received was reported by host
fedoranews.org, IP 64.34.165.170, your intended destination, for
not-very-well-explained reasons has turned surly and is declining mail
(yours, at least; probably others', as well).  However, let's trace the
progress of your message, so you can see how to interpret the DSN and 
the headers in your attached mail copy: 

First, consider the DSN text itself:

>    tchung at fedoranews.org
>      SMTP error from remote mail server after MAIL
> FROM:<martinjh at blueyonder.co.uk>:
>      host fedoranews.org [64.34.165.170]: 550 5.7.1 Access denied

The "host fedoranews.org [64.34.165.170]" part identifies what machine
is notifying you.  It's declining mail you addressed to
"tchung at fedoranews.org".  The DSN payload, which are the error code and
explanatory text (for small values of "explanatory" in this particular
case) are the final bit:

> 550 5.7.1 Access denied

Let's break that down.  It parses as:

o SMTP error code:  550
o SMTP extended error code:  5.7.1
o SMTP error text:  Access denied.

"550" is the classic (most common) permanent-failure SMTP error code,
though there are others.  The 5xx category are permanent failure
reports, i.e. "this is definitive, so there's no point in re-attempting
delivery" -- in contrast to the 4xx temporary-failure errors you will
often see, such as those ending with "Warning: message still undelivered
after 4 hours.  Will keep trying until message is 5 days old", and the
2xx series that indicate successful delivery.

I can't count the number of times people have telephoned me during my
mail server's scheduled downtime, complaining they got a "bounce
message" when they tried to mail me -- only to find out that the
diagnostic text, which they didn't bother to read, very clearly said
(paraphrasing) "I've been having some difficulty getting this message
through; it may be just a glitch, and there are still five days of
delivery attempts left, but I thought you should know."

A fair amount of thought has gone into making (most) DSNs informative;
it's a pity so many people can't be bothered to read them _at all_.

"550" and all the other SMTP error codes were defined in Jon Postel's 
classic RFC821 document, in 1982.  "550" is explained there as being
intended for "Requested action not taken: mailbox unavailable [E.g.,
mailbox not found, no access]" situations -- wording broad enough to
serve as a catch-all for most permanent delivery failures, other than
50x SMTP-command syntax errors, 551 "User not local" redirects, 552
"exceeded storage allocation" errors, 553 "mailbox syntax incorrect"
errors, and a vague-sounding 554 "transaction failed" that most often 
means "destination host is so overloaded that it's refusing some mail as
a coping strategy".

But don't forget my larger point that you needn't know that, to read the
error messages:  Generally, you just read the error text, and the
reason's _right there_.

"Access denied" in this case is, sadly, pretty delphic, and could mean
quite a lot of things, I suppose.

That brings us to "5.7.1":  RFC1821's definition of the SMTP standard in
August 1982 was, by a decade and a half later, wildly successful by any
measure, but among its nagging design defects was the limitations in its 
set of error codes.  Many were just not specific enough, and there were
very few unassigned code numbers left to fill in gaps.  Therefore,
"subcodes" were defined in January 1996's RFC1893, and follow a three-part
numerical format: "class.subject.detail".  

The leading "class" tuple uses the same numerical convention the earlier
SMTP error codes did:

2.X.X = success
4.X.X = temporary failure
5.X.X = permanent failure

Each of these is further specified by "subject" tuples for the middle
value:

X.0.X = this error concerns: other/undefined
X.1.X = this error concerns: sender or recipient address syntax/validity
X.2.X = this error concerns: recipient mailbox issues
X.3.X = this error concerns: recipient system problems
X.4.X = this error concerns: network or routing problems
X.5.X = this error concerns: failure somewhere in the mail delivery protocol
X.6.X = this error concerns: failure involving content-handling
X.7.X = this error concerns: security or policy failures

I could give a complete listing of the "detail" permutations (the third
tuple), but it'd be a bit long -- 49 entries -- because meaning differs
based on what values the other two tuples have.  The full list is in
RFC1893, but the one relevant to your mail is:

X.7.1   Delivery not authorized, message refused

          The sender is not authorized to send to the destination.
          This can be the result of per-host or per-recipient
          filtering.  This memo does not discuss the merits of any
          such filtering, but provides a mechanism to report such.
          This is useful only as a permanent error.

So, basically, this string you got -- "550 5.7.1 Access denied" amounts
to:  fedoranews.org thinks that you, your ISP, or the particulars of
your message shouldn't not be allowed to use it to send mail to
mailbox "tchung", for reasons basically unspecified but vaguely security
or filtering-related.  Assuming you haven't done anything to get Tom
Chung's knickers into a bunch  ;-> , possibly he has a misconfigured or
severely trigger-happy antivirus or antispam system?  Or there's bad
blood between fedoranews.com and Blueyonder?

Along those lines, the error was triggered at exactly the point where
your ISP's outbound SMTP server said to fedoranews.org

    MAIL FROM:<martinjh at blueyonder.co.uk>

Looks like something at fedoranews.org doesn't like specifically _your_
mailbox -- or your ISP.  Either way, it seems a bit ill-tempered, at
best.


You can follow the actual literal _progress_ or your message, up to the
point where fedoranews.com rejected it, in the pair of Received
headers sent back to you:

> Received: from [172.23.170.146] (helo=anti-virus03-09)
>       by smtp-out5.blueyonder.co.uk with smtp (Exim 4.52)
>       id 1FsLze-0003tl-GW
>       for tchung at fedoranews.org; Mon, 19 Jun 2006 16:48:50 +0100
> Received: from [62.30.33.77] (helo=[192.168.0.2])
>       by asmtp-out2.blueyonder.co.uk with esmtp (Exim 4.52)
>       id 1FsLzd-00033G-Ni
>       for tchung at fedoranews.org; Mon, 19 Jun 2006 16:48:50 +0100


Those are most-recent first, so you actually start reading at the bottom
and go up:

1.  MTA "asmtp-out2.blueyonder.co.uk" (presumably, your ISP's outbound 
SMTP host) received a message stream from IP address 62.30.33.77
(presumably, your workstation), addressed to tchung at fedoranews.org
asmtp-out2 then passed the message along to the next phase.

2.  That next phase is apparently some sort of additional outbound-SMTP
machine called "smtp-out5.blueyonder.co.uk" (maybe a Microsoft-virus
stripper?), which does the actual delivery to a mail exchanger for the
"fedoranews.org" domain.

How does it know where such mail should go?  We can simulate its
thinking processes using the "dig" command:  Mail should be dropped off
at a host indicated in the domain's "MX" DNS records.  If there are no
such records, it should be dropped off using the DNS "A" record for the
specified host+domain, as a fallback.

$ dig -t mx fedoranews.org +short
$
Null result on type "MX".  So, as mentioned, there's an automatic
fallback to "A" (regular forward lookup) records:

$ dig -t a fedoranews.org +short
64.34.165.170

3.  So, smtp-out5.blueyonder.co.uk attempted delivery to
"fedoranews.org" AKA IP address 64.34.165.170, where it ran into the
aforementioned security or policy-based refusal.

There's no "Received" header for this third hop because, well, the mail
was refused, after all.


Just as a word of caution, not all Received headers are honest:
Spammers, computer criminals, and some malware have been known to
attempt to inject bogus information or even one or more entirely
fraudulent Received headers, in an effort to deceive analysts trying to
track down responsible parties.  In general, any information in an SMTP
e-mail, including all Received headers, can be forged by any of the
prior machines that handled the mail, and must logically be subject to
doubt, except that the immediately prior MTA's IP address, before your
own, is known with certainty -- because it was recorded by _your_ MTA
at the time of receipt.

Thus, if you were the sysadmin of smtp5-out.blueyonder.co.uk, and
trusted your own machine (to not be root-compromised, etc.), then you
could rest assured that this mail really _did_ come from IP address 
172.23.170.146 .