On Thu, Jul 05, 2001 at 11:53:30AM +0200, "Daniel Erd�s" wrote:
>
>
>
> About one month ago I reported a strange behaviour when sending any mail to
> @whatever. It seems that those mails gets lost instead of sending to catchall or
> bounce.
>
> I debugged it and wrote that the problem should be one line in qmail-lspawn.c
> (please also see my mail below) referred to qmail-ldap-1.03-20010501.
>
> qmail-lspawn.c in function spawn():
> 772 if (!r[0]) _exit(0); /* <> */
>
>
> I did not find any comments to this till now.
> IMHO this line is the reason for my problem. What's the sense of it? My problem
> can be fixed if I just comment out this line.
> Is it Bug (Andre, Claudio)?
>
First of all, this is djb code (not modified by the patch), so you
probably have to ask djb why he is doing that.
But he will probably yell at you "READ THE RFCs!!!"
rfc 821 (SMTP) says:
The following are the SMTP commands:
...
MAIL <SP> FROM:<reverse-path> <CRLF>
RCPT <SP> TO:<forward-path> <CRLF>
...
The syntax of the above argument fields (using BNF notation
where applicable) is given below. The "..." notation indicates
that a field may be repeated one or more times.
<reverse-path> ::= <path>
<forward-path> ::= <path>
<path> ::= "<" [ <a-d-l> ":" ] <mailbox> ">"
<a-d-l> ::= <at-domain> | <at-domain> "," <a-d-l>
<at-domain> ::= "@" <domain>
<domain> ::= <element> | <element> "." <domain>
<element> ::= <name> | "#" <number> | "[" <dotnum> "]"
<mailbox> ::= <local-part> "@" <domain>
<local-part> ::= <dot-string> | <quoted-string>
and so on.
As you can see a regular forward-path consists of a non null local-part
"@" domain. So your @somewhere.com is invalid.
It is similar to the empty sender <> how was invented to prevent mail loops
for bounces. From the RFC 821:
If a server-SMTP has accepted the task of relaying the mail and
later finds that the forward-path is incorrect or that the mail
cannot be delivered for whatever reason, then it must construct an
"undeliverable mail" notification message and send it to the
originator of the undeliverable mail (as indicated by the
reverse-path).
This notification message must be from the server-SMTP at this
host. Of course, server-SMTPs should not send notification
messages about problems with notification messages. One way to
prevent loops in error reporting is to specify a null reverse-path
in the MAIL command of a notification message. When such a
message is relayed it is permissible to leave the reverse-path
null. A MAIL command with a null reverse-path appears as follows:
MAIL FROM:<>
Do you need more explanation ?
--
later
Claudio
mailto:[EMAIL PROTECTED]
