Bounce Address Tag Validation (BATV) enables your MEG appliance to ignore backscatter email message.

 

Quoting backscatter from KB69704 - Glossary of technical terms:

When spam or phishing messages use forged (spoofed) source addresses belonging to a company's domain, that company can be flooded with email bounces known as backscatter if the fraudulent email's recipient addresses do not exist. In the worst cases, a mail loop occurs when the message is bounced to a non-existent sender address.

 

 

The appliance can attach an encrypted digital signature (or tag) to the SMTP MAIL FROM address on every outgoing email message. When a bounced email arrives, the appliance searches for the digital signature, and rejects any message that has no digital signature or has an invalid digital signature.


BATV Configuration
You can enable BATV in the appliance GUI, Email, Email Configuration, Receiving Email, Bounce Address Tag Validation.

 

There are several configurable items. To enable BATV, simply check Enable bounce address tag validation option and apply the change. Your MEG appliance will populate the default BATV options - reject when validation fails, 7 days life time, and randomly generated signature seed. Below table shows the details about each option.

 

OptionDefinition
Enable bounce address tag validationSelect to configure BATV on your appliance.
Signature lifetimeSpecifies how long the signature seed will be used to sign outgoing email. Mail servers typically try to deliver mail for up to four days. McAfee recommend a value of 4–7 days.
Signature seed

Specifies a seed for signing the sender's address.

Use only letters, numbers and space characters. The acceptable key length is 4–64 characters. Type a seed that is not easy to guess.

GenerateWhen clicked, generates a signature seed that has 20 random letters and numbers. You can use this method instead of typing your own signature seed.
Protocol preset (available in MEG 7.5 and later)Select a Protocol preset to allow you to configure per-policy actions for BATV on your appliance.
When validation fails

Specifies how the appliance must handle each invalid bounced message. The available options are:

• Allow through 

• Reject 

 

BATV Behavior
Let's see how the appliance adds BATV tag and validates it.

 

Tagging
The appliance uses Simple Private Signature (prvs) scheme when BATV is enabled. If the original <local-part> is <someone@test.local>, the BATV <local-part> in prvs scheme will look like <prvs=KDDDSSSSSS=someone@test.local> where KDDD represents 4 digits and SSSSSS represents 6 hexadecimal letters.

 

If you enable SMTP Conversation Logging feature which I introduced in my last blog post, you can verify it on MAIL FROM in DELIVERY section. The attached screenshot below shows the conversation logging which records MEG appliance sent MAIL FROM:<prvs=0149c9be41=foobar@test.local> to the next hop MTA.

trim-conv_log.PNG

 

Validation
When the appliance receives null sender in SMTP MAIL FROM command and if BATV is enabled, the appliance validates RCPT TO email address. If it does not have valid prvs tag or invalid tag, the appliance will take BATV invalid action.

 

The attached screenshot below is from my Wireshark network analyzer. There are two groups of SMTP conversation, where the first group is for validation failure case, whereas the second group is for successful validation case.

trim-validation.PNG

 

In the first case, the conversation went in the following order where you can verify that RCPT does not have BATV prvs tag hence MEG returned 550 error code and rejected it:
Client sent to MEG: MAIL FROM: <>
MEG sent to client: 250 Requested mail action okay, completed.
Client sent to MEG: RCPT TO: <foobar@test.local>
MEG sent to client: 550 Invalid tag value.

 

In the second case, the conversation went in the following order where you can verify that RCPT does have BATV prvs tag hence MEG returned 250 success code and accepted it:
Client sent to MEG: MAIL FROM: <>
MEG sent to client: 250 Requested mail action okay, completed.
Client sent to MEG: RCPT TO: <prvs=0149c9be41=foobar@test.local>
MEG sent to client: 250 Requested mail action okay, completed.

 

During the above test, I manually typed the SMTP commands and sent QUIT after successful BATV validation. In a real MEG setup, client would send DATA command after successful BATV validation.

 

Note that BATV prvs tag value changes everyday and you have signature lifetime setting.