VARA = Verified And Recipient Authorized, a simple, public domain concept with applications in anti-phishing and fixing the forwarding problem for designated sender schemes. Consider suspending the thought that we are idiots and what we say about VARA is impossible. I'm not sure why but whether we say it forwards (from idea conception, concrete scenario examples, implementation) or backwards like this article which begins with benefits - it seems to take first a belief that we're not idiots, then several iterations of "BUT!" and then "Oh! I see..." and then "BUT!" again before the reader gets it.

Does it require consensus?

No, VARA works when implemented by one ISP for its own recipients, not requiring any other ISPs to agree or do anything special.

Can spammers and fraud perpatrators get around it?
No, dictionary attacks are automatically rejected and even if they have your VARA formatted address, they can't successfully send to it.

What can VARA accomplish?

These are each separate, and non-related benefits of VARA

1. Anti-phishing - Give your bank or other financial service a VARA formatted address. You are assured that ALL mail received at that address is legitimately from your bank - even if spammers and criminals obtain the address and try to send to it.

2. Solve the inbound forwarding problem for SPF - Automatically know when to skip the SPF check. The VARA formatted address says "skip designated sender tests, this is forwarded account mail." Now your SPF check has more weight / trustability, and you won't be marking mail your recipients want as spam - just because it failed SPF and you didn't have enough other info to pass it. Yet there is NO opening for spammers to get by the SPF check using the exact same delivery address.

3. User privacy and control over who can scrape, buy, or steal their address - Subscribe to an email list with a VARA formatted address - and you'll never get mail to that address that isn't from the list. Not from your fellow listmates, not from spammers who scrape web archives (and yes, scrapers CAN write around all the obfuscating techniques.)

How does the ISP implement VARA?

The inbound ISP checks RCPT for a pattern that represents "this is a VARA recipient." Those get a VARA test. Mail can be rejected pre-DATA if the sender fails the VARA test.

Coding to support the VARA test is very minimal. There is already a free VARA client for MS Exchange server and a python milter based VARA client for sendmail - both of which I have personally tested. The author of the milter states that it took him less than an hour to implement VARA in the milter.

Users normally create a VARA address or alias the same way they create any email address in your system. No lookup or database is needed, no separate listing or storing of VARA addresses separately from regular addresses.

So it's like Spam Gourmet or plus+detail or a throwaway address system or ...

NOOOOOOoooooooooooooooo! All of the "throwaway address" systems allow spammers and criminals to send to the addresses - then as a reaction, the user has to throw the address away. VARA prevents spammers and criminals from sending to the address in the first place, even if the spammer obtains the address or it is publically visible.

What if I don't like the delimiter in VARA?

Each ISP is free to use any delimiter or sequence of delimiters they desire - no standard is needed and no one else has to agree. So use whatever delimiter works for you. We are using one that works fine for us in the sendmail milter. The MS Exchange server plug-in actually lets the admin specify any delimiter or sequence he prefers.

VARA won't work for us because our user name system only supports periods, digits and a-z

The VARA wiki anticipates this objection and describes how huge ISPs even who only allow a-z for email addresses can use VARA. It may be simplest to do some back and forth discussion  to give you ideas how your specific ISP with its specific user restrictions could do so.

Misc objection responses:

Multi-hops do not cause VARA addresses to change or grow in any way nor do they require any knowledge of VARA,  cooperation or changes from forwarding services.

60 something character limit on email addresses is not challenged in the practical application of VARA. The rules for using VARA are simple: It works great for the vast majority of situations. If your email address is @wallalallapaloozijonessmithwalkrfruitcakejohnsonschmee.com then don't use VARA.

If your sender will come from a wide variety of constantly changing sources, then don't use a VARA address for that sender. Use your regular address. VARA works great for finanical services senders who have tight security policies, as well as large forwarding services and the majority of well-configured senders out there. It's not supposed to be used for mail from your Aunt Clara.

No harm will come to people who don't use VARA - "everyone must do it or it won't work for anyone" doesn't apply for VARA.

What does a VARA address look like and give me a scenario example:

You'll find examples here

http://wiki.outboundindex.net/VarA

http://wiki.outboundindex.net/APreciseDefinitionOfVARA

but let me warn you as before that people seem to always read them incorrectly even tho we really think we have stated them quite simplistically. It helps a lot to be talking and pointing with a person who does understand VARA. We would like to do a visual simulator for the website and - we'll be getting to that in our spare time (wink) since this is a volunteer, profitless, public domain offering.