On Wed, 2 Sep 1998, James Dehnert wrote:
> I'm also seeing the following delivery message errors...
>
> SMTP>> MAIL FROM:<>
> SMTP<< 555 syntax error (#5.5.4)
The receiving server is broken. I attach below a stock message I use to
send to the postmasters of such sites. I edit the detail as necessary
each time, and usually append a telnet session to make it absolutely
clear.
> MAIL FROM:<jdehnert@???>
> 555 syntax error (#5.5.4)
Wow! That is *really* broken, worse than the more common "failure to
accept <>" problem.
> Jim_Wiebmer@???:
> SMTP error from remote mailer after RCPT TO:
> <Jim_Wiebmer@???>:
> host fw3.dsccc.com [192.245.102.13]:
> 571 <Jim_Wiebmer@???> ... we do not relay
Looks like they've screwed up their relaying configuration as well.
However, this doesn't seem to be a problem from my host:
220 fw3 SMTP/smap Ready.
helo ursa.cus.cam.ac.uk
250 (ursa.cus.cam.ac.uk) pleased to meet you.
mail from:<ph10@???>
250 <ph10@???>... Sender Ok
rcpt to:<Jim_Wiebmer@???>
250 <Jim_Wiebmer@???> OK
... and in fact MAIL FROM:<> works from here too. Perhaps they fixed the
problem?
> I'm begining to believe that this isn't an exim problem, but I havn't
> a clue yet, soooo..
It does not appear to be an Exim problem.
--
Philip Hazel University of Cambridge Computing Service,
ph10@??? Cambridge, England. Phone: +44 1223 334714.
-----------------------------------------------------------------------
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.
[I include this bit if telnetting to their server's SMTP port shows that
it is running Sendmail. I usuall include the telnet session here too.]
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
--
*** Exim information can be found at
http://www.exim.org/ ***
