• ITS home
• Help
• Services
• My IT account
• Security
• About

Questions and answers

1101

What is sender verification?

Sender Verification is a technique used to check that incoming email comes from a real or deliverable email address on a mail server that conforms to international standards for email.  It is designed to help block spam, but unfortunately can result in some genuine email being rejected. This technique is used not only by the University of Sussex but also an increasing number of other institutions (including Cambridge, Exeter and Brighton universities).   Sussex has been operating sender verification on its mail systems since January 2004.

WHAT HAPPENS
When a mail message is received by the Sussex mail server it makes a call-out back to the sender's mail server to see if it will accept bounced email for the sender's address.  This doubles as a 'sender verification' test.  If the remote server does not respond, or signals that it does not accept bounces,  the Sussex server assumes that the sender address is not valid, and rejects the incoming message.  Many bogus email systems, such as those used for spamming, will not accept bounced email, and our system blocks them in this way.

In more technical terms, an SMTP 'MAIL' command is sent using '<>' as an "empty reverse path". This is specifically defined in a formal document, RFC 2821 section 4.1.1.2, as a valid argument for the SMTP 'MAIL' command.  The mechanism used is exactly the same as that used to bounce undeliverable messages, and to send delivery receipts and autoreplies.  The sender verification mechanism (and by definition the mechanism for bouncing, delivery receipts and autoreplies) depends on this command being accepted and recognised by the remote system.

Unfortunately this mechanism does mean that the Sussex system will sometimes reject email from people from whom you really do want to receive email. This will always be because the sender's mail server (or that of their service provider) is not correctly configured.  Unfortunately, some vendors of email systems make it very easy to configure a mail server incorrectly.

In summary, a mail server misconfigured in this way,

• Will not accept bounce messages;
• Will not accept auto-replies;
• Will not accept receipt-confirmation messages;
• Will not be giving its users or customers a complete service and will likely cause them problems.

WHY DO WE BOTHER WITH SENDER VERIFICATION?
There is nothing arbitrary about Sussex's refusal to accept mail from misconfigured servers, and it is increasingly common for mail servers to do so. Essentially, a misconfigured server gives us no way to notify the sender if mail delivery should fail. If we accepted mail from such servers there is a risk of losing it altogether because we would be unable to bounce back an undeliverable message.  It would also mean a huge increase in the amount of spam being delivered to everyone.

Senders of blocked messages should be notified by their mail service provider that their emails are not being delivered. The notification should include a copy of the error message that we generate. If email service providers do not honour sender verification checks, this by definition means that they do not accept bounce notifications either, so their customers will not be getting a complete, trouble-free mail service.

The key to this policy is not what we do at Sussex, but why - and how we justify it.  If the sender's email service provider is not using internet standard email, they cannot expect their email to work correctly on the internet. The most important issue is that internet mail standards (defined in formal documents called RFCs) require servers to accept mail with an empty sender address, which is part of the mechanism of sender verification and bouncing of messages.

The formal requirements can be viewed in sections 3.7 and 4.1.1.2 of RFC 2821 and section 5.2.9 of RFC 1123. The latter states that "An empty reverse path MUST be supported."   See also the Wikipedia article about RFCs.