3

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?

Community
  • 1
makerofthings7
  • 50,090
  • 54
  • 250
  • 536

2 Answers2

2

Many systems support the use of alias with a character such as +. So, makerofthings7+c6201404b8efbe@invalid-email.com would be equivalent to makerofthings7@invalid-email.com for the MDA (ie. they would end up in the same mailbox).

Then, you keep a list of whitelisted tokens (maybe paired with the From header they must use): makerofthings7+c6201404b8efbe@invalid-email.com makerofthings7+f20bb519c3c78a@invalid-email.com makerofthings7+50d45bcae94598@invalid-email.com makerofthings7+ecdbe0890dd0c2@invalid-email.com

If someone sends you an email to an address in your list, it gets blacklisted. If it's not, it's automatically treated as spam (to avoid token-guessing). Obviously, if a good token gets compromised, you replace it ;)

The whitelist doesn't need to be stored in the MTA, the filtering can be done locally. For offline uses, you can create in advance a bunch of whitelist tokens. Or even made them up on the fly as long as you update the whitelist checked by the filter before it processes that new mail.

This has existed for some time, I don't remember when I first about it. The best part is that it works today, without having to instruct MUAs about a new X-WhitelistReplyAddress header.

One big difference with your recipients-hashing is that in your solution there is a single key from which the tokens are derived, while here they are randomly generated tokens that you need to list (although you could replace the search the token in the list with check that it matches the right token if coming from this guy). But if a hash-based whitelist token gets compromised, you can't remove it without rekeying everybody's tokens, while in the other approach you can easily replace a single token (moreover, if you keep records of the entities you gave your email, you can find who leaked/sold your email address).

Ángel
  • 17,578
  • 3
  • 25
  • 60
1

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.

Thomas Pornin
  • 320,799
  • 57
  • 780
  • 949