Why can't I block emails from <>?
I have noticed that some spam comes from an address of <> so I would like to ban all such email. If I did this, what would be the consequences?
This KB article is a copy of RFC821 (the Internet Mail Standard for email). It states that servers MUST accept email from <> so that status reports can be returned to senders of email messages.
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
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:
An undeliverable mail notification message is shown in example 7 (below).
This notification is in response to a message originated by JOE at
HOSTW and sent via HOSTX to HOSTY with instructions to relay it on
to HOSTZ. What we see in the example is the transaction between
HOSTY and HOSTX, which is the first step in the return of the
Example Undeliverable Mail Notification Message S: MAIL FROM:<> R: 250 ok S: RCPT TO:<@HOSTX.ARPA:JOE@HOSTW.ARPA> R: 250 ok S: DATA R: 354 send the mail data, end with . S: Date: 23 Oct 81 11:22:33 S: From: SMTP@HOSTY.ARPA S: To: JOE@HOSTW.ARPA S: Subject: Mail System Problem S: S: Sorry JOE, your message to SAM@HOSTZ.ARPA. S: HOSTZ.ARPA said this: S: "550 No Such User" S: . R: 250 ok Example 7
Keywords:SMTP null MAIL From <> undeliverable RFC821