Some questions about anti-UBE rules

Last Update 1999-02-24
Here are some answers and thoughts about anti-UBE ideas which come up from time to time.

How do I reject "MAIL FROM:<>"?

Don't do it! Internet standards require to accept e-mail with an empty sender address, i.e.,
MAIL FROM:<>
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.
(emphasis and links added by me). Error messages (in general: delivery status notifications) are sent this way, so they must not be rejected.

How do I reject mails with local sender addresses coming from external systems?

In general, that's another bad idea. Let's assume the following: YOUR.DOMAIN is the name of your domain (intuitive, isn't it?), and some user at REMOTE.DOMAIN installs a .forward file at REMOTE.DOMAIN which says:
user@YOUR.DOMAIN

Next, someone from YOUR.DOMAIN sends an e-mail to that user at REMOTE.DOMAIN which gets forward to user@YOUR.DOMAIN That is, your server receives an e-mail with a local sender address and a local receiver address, which is relayed from a remote system (REMOTE.DOMAIN).

If you would reject those mails, the above scenario would break. Can you make sure that this scenario won't happen?


Other proposals what should be in this text? Send me an e-mail. Thanks.


[(links)] [Hints] [Avoiding UBE] [cf/README] [New]
Copyright © Claus Aßmann Please send comments to: <ca@sendmail.org>