Some questions about anti-UBE rules

Last Update 2002-06-16
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.,
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.

Guess what? Some people can't read and they have a setting in their mail server (IMail 4.0+ for NT) that rejects those addresses. Why are people allowed to distribute (sell?) such software? (they probably take some other company as bad example...).

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

In general, that's another bad idea to deal with faked e-mails. 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:

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? If you can, you may take a look at a proposal from Ted Deppner. However, you have to change it for 8.9. Note: this hack is not supported by me.

Note: Sender addresses can't be trusted unless you can verify them. In ``real life'' you usually trust a signed letter, at least if you can verify the signature. For e-mail, you should do the same: don' trust it unless it is digitally signed and you can verify the signature. Even then, the senders system could be compromised, but that's similar to a faked signature on a letter.

How do I reject mails whose domain part does not match the sending host?

Some people want to reject mail whose domain part does not match the domain name of sending host. For example: If the sender address is <user@one.domain> but the sending host has a name in a different domain, e.g, other.domain.

This works only in a few cases, but will reject many legitimate e-mails. For example, almost all members of the Sendmail consortium use
as sender address when answering questions, however, at most one of them actually sends mail from a machine in that domain.

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

Remember: the net was there before the spammers. Don't let them destroy it by overreacting.

[(links)] [Hints] [Avoiding UBE] [cf/README] [New]
Copyright © Claus Aßmann Please send comments to: <ca at>
Disclaimer: the information provided may be inaccurate or outdated or incomplete. Please contact me if you find an error.