[Top] [All Lists]

Re: stupid SMTP rejection of spammers

2001-06-15 11:35:03
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
local delivery.

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 
'postmaster(_at_)broken(_dot_)address', along
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...

                                Valdis Kletnieks
                                Operating Systems Analyst
                                Virginia Tech
--- 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 (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

Attachment: pgplYA8XCy80K.pgp
Description: PGP signature