smtp-cbv
by
Chris Drake
Please consider my idea. Skip a page down to the "PROPOSAL" section
if you wish to avoid my "rant" preamble voicing my discontent with
SPF, CID, etc.
I propose an alternative to SPF, CID, Domainkeys, sender-id, etc -
hereafter referred to as "SMAM" (sender/message authentication
mechanisms).
Problems:
SMAM rejects sender emails when ISPs or other administrators overlook
the needs of their customers to send mail outside of the ISPs
SMTP server setup. Experience reveals that SMTP admins
infuriated by spam (or infatuated with antispam) regularly
overlook the needs of their customers.
SMAM silently erases sender emails when it's used in a spam-scoring
environment.
SMAM isn't designed as a major anti-spam tool, and the overwhelming
majority of people looking at SPF are doing so primarily as a
means to solve spam problems.
In 5 years or so, SMAM will be having little or no noticeable impact
on spam - spammers will either comply with SMAM rules, or use non-SMAM
enabled services to send from.
Some SMAM techniques destroy "cottage email industries" like
forwarding services, message time-stamping, mailling lists, and other
things.
NOTICE OF INTEREST: I (Chris Drake) operate a small email service
facing such potential annihilation.
PROPOSAL
I propose "SMTP-CBV" (Simple Mail Transport Protocol - Call Back
Verification) as an alternative to SMAM - here's an SMTP-CBV flow
as an example:-
[Flow step 1] Originating MTA (OMTA) contacts Recipient MTA (RMTA) and
issues the usual HELO, MAIL FROM, RCPT TO, and (for SMTP-CBV fluent
OMTAs) a custom VRFY line.
[Flow step 2] OMTA enters DATA phase and sends the message.
[Flow step 3] RMTA accepts HELO, MAIL FROM, RCPT TO, optional VRFY,
and DATA commands, and opens a socket to the MTA of the MAIL FROM
domain (hereafter called the VMTA - which may be the OMTA itself, or
the usual MTA associated with the OMTA, or some other MTA/custom CBV
process controlled by the ISP)
[Flow step 4] RMTA issues a HELO, then a custom VRFY command, then a
MAIL FROM: using the recipient address of the earlier "RCPT TO"
command, then a RCPT TO using the address of the earlier "MAIL FROM"
command, then a DATA command, the RMTA closes the socket (terminates
connection without sending any data).
There are 2 custom VRFY commands in SMTP-CBV.
VRFY # 1
The first (optional) VRFY is sent by the OMTA at the time of sending
("Flow step 1") the original email message. It communicates the
following information, which is extensibly formatted to look like an
email address:-
1. OTMA SMTP-CBV version,
2. optional OMTA SMTP-CBV features/requests/etc
3. The emails MESSAGE-ID
This is an arbitrary example:-
VRFY:<cbv1-option#value-mid#40D6B521(_dot_)11FB(_at_)xyzzy(_dot_)claranet(_dot_)de>
cbv1 this is version 1 of SMTP-CBV
- component separator
option#value arbitrary SMTP-CBV options the OMTA wants the RMTA to
consider (for example: use some other callback
mechanism/server than the default)
- component separator
mid#40D6B521(_dot_)11FB(_at_)xyzzy(_dot_)claranet(_dot_)de
the last part (rest) of this custom VRFY line is the
(prepended with mid#) MESSAGE-ID of the message that
will follow in the DATA phase.
The RMTA can respond to this VRFY command howsoever it likes, the
recommended implementation will be to communicate back to the OMTA
its own SMTP-CBV version/support-matrix/whatever else.
SMTP-CBV-unaware RMTAs will reply "550 no such mailbox" or the
like, which at least lets the OMTA know that SMTP-CBV isn't spoken
there.
SMTP-CBV-unaware OMTAs won't send this VRFY command of course.
VRFY #2
The second VRFY command ("Flow step 4") is sent by the RMTA back to
the VMTA to do the call-back verification on the received email
(unless prohibited by an "option#value" set by the OMTA). Here's an
arbitrary example of what this VRFY line might look like:-
VRFY:<cbv1-OMTA#203(_dot_)217(_dot_)12(_dot_)33-mid#40D6B521(_dot_)11FB(_at_)xyzzy(_dot_)claranet(_dot_)de>
The purpose of this line is:-
1. It informs the VMTA that this is a CBV request, and not an incoming
email
2. It provides the VMTA with the Message-ID of the email that's being
verified, (thereby allowing the VMTA to specifically authenticate
individual messages if desired).
3. This example uses the "option#value" mechanism to tell the VMTA
of the IP address of the MTA which caused this CBV lookup. It will
probably be a "REQUIRED" parameter.
4. It gives the VMTA an opportunity to communicate back to the RMTA
for whatever purpose.
5. If the VMTA does not understand SMTP-CBV, there is sufficient
"junk" in this VRFY data that it should always fail (that email
address wont exist) - this failure tells the RMTA that SMTP-CBV is
not specifically implemented, so the RMTA can examine the response
(either "550 no such mailbox", or, a note about VRFY not supported,
or a favorable response indicating that the VRFY email address
"does exist" [which tells the RMTA that the VMTA probably
implements dictionary-attack-prevention and will probably respond
"OK" no matter what address it tries to verify subsequently])
[Verification Step] The end of "Flow step 4" uses the above info to
verify that the sender really exists, and/or that they really sent an
email to the named recipient and/or that the email they sent was the
one specifically identified by the message id and/or that the incoming
MTA which delivered the message is allowed to do so.
SMTP-CBV Implementation theology:
It is NEVER acceptable to erase a legitimate email without warning
(the sender) - NEVER EVER.
SMTP-CBV Pros:
It works *right now*, on the majority of RMTAs, without them having to
do or change anything.
It doesn't break anything. Forwarding works. Email add-on services
still work. Nobody except spammers should suffer losses.
It allows the message to be "rejected before DATA" if the OMTA talks
SMTP-CBV (thus letting the sender know that it did not go through)
It allows both the OMTA and RMTA operators to pick and choose what
"verification" they want to use, from the list I mentioned in
"[Verification Step]" above.
Extensibility is inbuilt.
The RMTA can "QUIT" the CBV connection earlier than DATA if it likes
(eg: the non-SMTP-CBV-aware VMTA responds "550 no such mailbox" after
the RCPT TO)
VMTA can be a different server (specified or "allowed" by a new "DNS
TXT" record, so spammers don't just set up their own VMTAs). VMTA
servers can speak TCP/IP SMTP, or use a SMTP-CBV custom UDP protocol
for extreme efficiency.
Small operators can use their existing MTA as the VMTA.
Can also work with SPF (helpful to prevent DDOS problems, however,
DDOS is a relatively minor issue "its unfortunate, but acceptable,
that a dozen or so spoof victims will be DDOSed by unscrupulous
spammers for a day or so, while the half a billion users of email who
(dont use SPF and) are rejecting those spoofs call back to check it
was a real email"). As SMTP-CBV spreads, spammers will not spoof
emails from SMTP-CBV equipped domains (thus preventing DDOSes on
them), nor will they spoof emails from non-SMTP-CBV equipped domains
(because the DDOSed domain won't be "online" to accept the CBV, so the
SMTP-CBV equipped RMTA will "4XX-try again later when your VMTA is up"
reject their spams)
Allows potential spoof victims to know that abuse is imminent
(example: a bank will know when a flood of CBVs hit its VMTA that a
phishing attack has just been launched, and who the victims are, and
what the offending MTA was)
Shifts the cost of sending slightly back towards the sender (who now
has to host a server (eg: a TCP/IP SMTP server, or a custom TCP or UPD
VMTA server) which can accept an incoming connection for every
outgoing email it sends), and preferably keep a "queue" of sent
message IDs (which is "popped" upon CBV to prevent replay abuse).
Prevents dictionary attacks, since the RMTA can verify the sender
before letting the attacker know if the recipient exists, and (if the
attacker speaks SMTP-CBV) gives the RMTA a "constant" (the VMTA IP
address) to use for throttling attack speed.
Enhanced DSNs can let the sender know that their message "passed the
recipient spam filters" and any other info that an MUA might like to
use for "prettying up" the user interface.
RMTAs can optionally (remove any existing) and then introduce a new
"SMTP-CBV-PASSED:" header to communicate to the recipient MUA the
status of this email (eg: eye-candy so the recipient knows the status
and extent of the CBV authentication)
No patents (indeed - now this informal RFC is in the public domain,
none are even possible).
No legal or moral liability problems (SMTP-CBV cannot erase emails
without warning (nor will it allow others to do so) so the legal and
moral problems associated with ISPs or other organizations using this
technology on behalf of their customers are avoided.)
Most importantly - it helps reduce emails getting deleted without the
sender knowing, because the necessity for anyone to use "scoring" or
other unreliable anti-spam technology is dramatically reduced, and
because SMTP-CBV has no mechanism whatsoever to ever erase an email
without warning. If SMTP-CBV should ever become a real RFC, I'll
include a requirement that "SMTP-CBV MUST NOT be used in any part of
any "spam scoring" system where any result will reduce the recipients
chances of getting their email"
[ I WELCOME ADDITIONAL PRO's - please post anything you can think of ]
SMTP-CBV Cons:
More than doubles the number of incoming SMTP connections to
non-SMTP-CBV equipped OMTAs ("more" because any "CC:" or "BCC:" email
will trigger >1 CBV)
To prevent replay abuse, OMTA may want to keep a database of
sender+recipient+message-ID
[ I WELCOME ADDITIONAL CONS's - please post everything you can think
of ]
Please comment liberally, but I ask that before you hit the "flame
button" try and think of a way to make yourself happy, and instead
phrase your "flame" as a suggestion. For example:
Flame: "You suck. I don't want my server getting DDOSed each time I
send out my newsletter"
Suggestion: "Please implement a way to specify an alternate VMTA, or a
way to ask the RMTA not the CBV me at all, because my
company sends a million emails every day, and we can't
afford a new VMTA UDP server capable of a million UDP
packets each day."
Flame: "You suck. I don't want to get DDOSed when spammers spoof my
domain"
Suggestion: "It would be a good idea to make SPF a mandatory SMTP-CBV
prerequisite"
Flame: "You stupid idiot - it does nothing to stop phishing, nyer nyer
nyer"
Suggestion: "Using the extensible mechanism to include checking of the
From: header would be a good idea"
Flame: "ACME co. MTAs can't understand VRFY after MAIL FROM:"
Suggestion: "VRFY #1 needs to come first, because... "
Also - some obvious things go without saying:-
Flame: "What if the MESSAGE-ID in the "VRFY #1" doesn't match what
comes in the DATA portion"
Obvious: "Reject after data".