Re: [EXIM] SMTP error

Top Page
Delete this message
Reply to this message
Author: Philip Hazel
Date:  
To: Griffiths M (ISD)
CC: 'exim-users@exim.org'
New-Topics: Re: [EXIM] Problem with Return-path
Subject: Re: [EXIM] SMTP error
On Thu, 5 Feb 1998, Griffiths M (ISD) wrote:

> I know this not exaclty be an Exim conf. type question but I am getting
> the following SMTP
> error message from a remote host that is freezing mail in our Exim
> queue.
>
> SMTP error from remote mailer after MAIL FROM: <>: host
> xxx.xxx.xxx.ac.uk [nnn.nnn.nnn.nnn]: 554 buildaddr: no net
>
> Any ideas what the error "554 buildaddr: no net" error means?


It usually means the far end is running an MTA that does not conform to
RFCs 821 and 1123 in that it does not recognize

MAIL FROM:<>

as the RFCs require. It is often a misconfigured sendmail. I have this
stock message I sent to the postmaster of such hosts:

---------------------------------------------------------------------
Hello!

The system xxxxx.xx.xx.xx is refusing to accept an SMTP mail message from this
system (cus.cam.ac.uk). The message is an error message, caused by receipt of a
message for an unknown user. This system sends out such messages using the SMTP
"from" command in the following format:

MAIL FROM:<>

This is a standard SMTP usage to indicate an error message that should not
itself generate another error message. Here are two extracts from RFC1123:

      5.2.9  Command Syntax: RFC-821 Section 4.1.2


         The syntax shown in RFC-821 for the MAIL FROM: command omits
         the case of an empty path:  "MAIL FROM: <>" (see RFC-821 Page
         15).  An empty reverse path MUST be supported.


[...]

      5.3.3  Reliable Mail Receipt


         When the receiver-SMTP accepts a piece of mail (by sending a
         "250 OK" message in response to DATA), it is accepting
         responsibility for delivering or relaying the message.  It must
         take this responsibility seriously, i.e., it MUST NOT lose the
         message for frivolous reasons, e.g., because the host later
         crashes or because of a predictable resource shortage.


         If there is a delivery failure after acceptance of a message,
         the receiver-SMTP MUST formulate and mail a notification
         message.  This notification MUST be sent using a null ("<>")
         reverse path in the envelope; see Section 3.6 of RFC-821.  The
         recipient of this notification SHOULD be the address from the
         envelope return path (or the Return-Path: line).  However, if
         this address is null ("<>"),  the receiver-SMTP MUST NOT send a
         notification.  If the address is an explicit source route, it
         SHOULD be stripped down to its final hop.


Unfortunately, some users of sendmail have configurations that don't handle
this correctly. I suspect that the following line is missing from ruleset 3 of
your /etc/sendmail.cf file:

R<>             $@@             return magic token


This is documented in, for example, Sun's System and Networking Administration
manual, in the section on customizing sendmail configuration files. Nothing
much seems to be said about it, but the example contains this line, as do the
standard configuration files distributed by Sun.

I will edit the current offending message so that it is acceptable to your
system. However, I suggest you consider fixing your configuration file, because
many other systems on the Internet use this convention and, indeed, the RFC
requires it to be honoured.

Regards,
Philip
---------------------------------------------------------------------

Sometimes I telnet to the remote host and try the MAIL FROM command just
to check. The way to get the message delivered is to use the Exim
command line options, or the equivalent Eximon options to change the
sender of the message from "" to "mailer-daemon@???" and then prod
it.

-- 
Philip Hazel                   University Computing Service,
ph10@???             New Museums Site, Cambridge CB2 3QG,
P.Hazel@???          England.  Phone: +44 1223 334714



--
*** Exim information can be found at http://www.exim.org/ ***