Take the 2-minute tour ×
Information Security Stack Exchange is a question and answer site for Information security professionals. It's 100% free, no registration required.

Problem Statement

I'm looking at ways to ensure that business partners, or emails from trusted senders, never get quarantined; ....in other words prevent "ham being seen as spam". Ideally this would guarantee delivery even if the sender was marked as a spammer (...see blackhole list).

Since most email is going through cloud / multi-tenant / shared email providers that share the same IP space, it's likely that the reputation of many different businesses are affecting each other for better or worse. That is, spammers may benefit from being co-located on "good" tenants, and conversely the "good" tenants may be blacklisted if the spammer gets the IP space listed.

Current email whitelisting solutions requires special action by the recipient, and that database to be maintained on a MTA. But there are many instances where this isn't feasible or the right solution, such as when offline, at a trade show, or wherever a receiver wants to ensure delivery of a sent message without logging into a web portal or updating Outlook junk mail settings.

Proposed Design

If we modify the TO email address, but prepended with a special value, such a hash, (similar to how BATV works), the MTA / SPAM engine could patently ignore the message and accept it as-is. Here is what a message would look like:

// The sig below will only guarantee delivery 
// for a sender of bill@microsoft.com
// to the account user@company.com
trust=xxxxxxxxxxxxxxxx=user@company.com 

// The sig below will only guarantee delivery 
// for a sender of alex@microsoft.com
// to the account user@company.com
trust=yyyyyyyyyyyyyyyy=user@company.com 

The hash (defined as a HMAC) trust would be the first 80 bits from the function:

(SHA256(Key + Lowercase From + Lowercase To))

When the receiving MTA receives the message with the special address, it will be able to validate the HMAC quickly, and avoid any greylisting or other anti-spam techniques that might be applied.

Assume that either each user is given the salt for their own ability to distribute hashes, and a copy of each hash is available to the MTA for verification purposes.

Making it secure/spoof free

Since anyone could conceivably spoof the tuple of "FROM" and "TO" address above, I think it's a good die to combine this feature with anti-spoofing measures such as DKIM or SPF, which is best defined in the DMARC standard

Usage

For in-person, offline whitelisting

This idea is best fit for times when you meet someone at a trade conference, bar, or and want to make sure you receive messages from that person. You don't want any Anti Spam solution getting in the way from them receiving your email. You would enter in their email address into your generator to create the following address trust=yyyyyyyyyyyyyyyy=user@company.com

Sample QR code for trust=yyyyyyyyyyyyyyyy=user@company.com

This two step process of generating the address could be automated in a variety of applications such as Facebook, LinkedIn, or Bump for iPhone.

For online- email whitelisting

In addition to setting the Reply-To: header, The MUA (email client) could insert a special X-header

X-WhitelistReplyAddress = trust=yyyyyyyyyyyyyyyy=user@company.com

Question

  • Is the "big picture" goal of this idea reasonable? (offline whitelisting, guaranteed delivery by MTAs, moving the location of the whitelist from the centralised mail server to the actual senders)

  • Is there any similar, existing proposed RFC that whitelists trusted sender-recipient pairs this for email?

  • What other techniques exist to whitelist sender-receiver pairs in email?

  • What cryptographic components are appropriate for this solution? Is hashing the right way to go?

share|improve this question
add comment

1 Answer

Hashing is not the right cryptographic tool; what you want is a MAC.

Your point is that you want some emails to go through antispam filters, but since you do not want spammers to use the same path (obviously), you are ready to enforce the use of an extra field in the email, which would contain some authenticating value that, hopefully, spammers cannot forge. To make it easier, you encode that extra field in the recipient email address, because that's one field that sender fill in anyway. This calls for a MAC and that's what you are trying to use in your formula:

SHA256(Salt + Lowercase From + Lowercase To)

Call "Salt" a key, and you have a homebrew MAC (a poor one, actually), which could be replaced with HMAC.

You must take care of the whereabouts of the key. The key is used to generate the token (the "To:" address, if you prefer to see it that way), and also to verify such tokens. A spammer would really like to get his hands on such a key, because it would allow him to send spams which evade the antispam filters. But the key must be hosted on some online systems (both in the App which generates the token, and in the MTA server which verifies incoming emails), which is rarely a good thing for long-term confidentiality. Also, the key cannot be easily changed since it would break previously published email addresses.


This system will make any good only as long as you can educate senders into using a custom tool to compute the token (to be integrated in the "To:" address), and also convince them to actually type that ugly-looking address (people rarely revel in the glory of hexadecimal). On the same time, you must not make the system too automatic, because otherwise spammers will adapt and use it, defeating the purpose. The right balance is often hard to strike, in particular because a prospective customer on a trade show often exhibits less brain power than even the average spammer.

Also, many sysadmins won't like it at all: a system meant to avoid antispam filters is also a system which will allow users to send executable files to each other -- a virus feast will be feared.

To sum it up, I don't see the system as really practical. It will create more usability problems than it resolves.

share|improve this answer
    
Thank you for the clarifications on HMAC... though I intentionally omitted AV scanning, just SPAM processing from this. –  makerofthings7 Aug 21 '13 at 18:32
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.