On Fri, 15 Jun 2001 19:48:05 +0200, =?ISO-8859-1?Q?Patrik_F=E4ltstr=F6m?= said:
Start by writing a paper about "BCP of SMTP operation".
(1) Don't block empty envelope from:
(2) Don't say ok to a recipient address if you are not 100% sure you can do
You're preaching to the choir, Patrik. ;)
(1) and (2) are/were both required all the way back in RFC821, as amended
by RFC1123. (Actually, the requirement for (2) is "unless you are 100% sure
you can either deliver or forward" - think about the case of a front-end
to a mail cluster at a large site),
If the <bleep>heads won't follow RFC821/1123, why do you expect they'd
pay any attention to a new BCP?
(technical note here - LSoft's Listserv product generates mail that has
an origin of <> for all its automatically generated replies to subscribe
requests and so on - mail posted "from a list" goes out with an owner-
Personally, I have a little hook into EXMH, that whenever my Listserv machine
bounces me a mail that got rejected because the other end rejects <>,
I just hit a key and forward the mail to
with a copy to the user, so maybe the *user* will yell at the admin for
running a broken mailer and causing them to fix things.
I've appended my canned message, if anybody cares...
Operating Systems Analyst
--- start canned message
:We attempted to send mail to your site, which rejected it on the
:grounds that it had a null reverse path in the MAIL FROM: SMTP
:command. 'MAIL FROM:<>' is how other systems send your system error
:notifications. Refusing to accept them means that your users will
:never know if their mail was handled sucessfully.
:Usually, null reverse paths are refused because of a misguided attempt to
:stop "spammers" from sending mail through your site. There are other,
:better ways to address this problem.
:Mail software known to be affected:
:Port 25 banner:
:220 X1 NT-ESMTP Server your.host.here (IMail 4.04 21974-1)
: This software incorrectly gives a '501 bogus mail from' error.
:Port 25 banner:
: This software incorrectly gives a '550 Access denied' error.
:The relevant sections of the Internet RFC standards and a copy of
:the rejected mail follow.
:RFC821, section 3.6 says:
: 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:<>
:RFC1123, section 5.2.9 says:
: 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.
:RFC1123, section 5.3.3 says:
: 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.
: Valdis Kletnieks
: Computer Systems Senior Engineer
: Virginia Tech
Description: PGP signature