spf-discuss
[Top] [All Lists]

Re[2]: Informal request for comments (a new SMTP-CBV protocol)

2004-06-21 15:47:19
Tuesday, June 22, 2004, 12:29:11 AM, Tony wrote:

TF> On Mon, 21 Jun 2004, Chris Drake wrote:

[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).

TF> It would be much cleaner to RSET and QUIT instead of say DATA and
TF> drop the connection.

Yes, but loads of existing MTAs delay the "550 no such user" response
until the DATA command.  An SMTP-CBV-aware VMTA responds differently
to the VRFY command, so in those cases, the DATA command isn't needed,
so RSET/QUIT can be used then.

TF> When is the result of the callout communicated to the OMTA? After
TF> CRLF.FRLF? As the response to DATA?

results are communicated at any time, for example:-

VRFY:<cbv1-option#value-mid#40D6B521(_dot_)11FB(_at_)xyzzy(_dot_)claranet(_dot_)de>
550 5.7.1 cbv1-msg#123-emsg#This server prohibits CBV

TF> Note that this protocol doesn't prevent joe jobs, because the
TF> forger won't advertise ChrisDrakeCBV regardless of whether the
TF> forged domain normally would.

The forged domain gets the opportunity to advertise it's CBV support
in response to the VRFY command given to the VMTA (which can't happen
if SPF is also supported, since the joe-job would not have been
acceptable enough to trigger a CBV anyhow).

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.

TF> This paragraph disagrees with the protocol you described.

How so?  I can't imagine a scenario where any high-speed dictionary
attack is possible.

My last few months worth of dictionary attacks happen like this:-

I get about 100 connections in each 24-hour period from 100 different
IP addresses and 100 different (probably forged) MAIL FROMs, each then
attempts around 100 RCPT TO's (almost always including at least one
deliberately impossible recipient address - presumably to detect my
MTAs point at which it advertises nonexistent mailboxes). The attacker
usually also includes an empty DATA portion (triggering a completely
blank email to any victims that got identified) and then disconnects
(usually without the QUIT too).  Between 3 and 36 hours later, new
spams begin to flood the identified mailboxes - here's the first of
one to an unused account of mine: "Subject: Hi Amanda All Drugs Here.
Get It All. thy sderqyzfw amble" - it arrived from a DSL pc (which I
portscanned - a socks5 zombie).

The RMTA can detect and throttle ("4xx try later") the attack when the
threshold for nonexistent RCPT TO's requiring CBV to any specific VMTA
IP hits the RMTA site-defined threshold (for large-scale zombie
attacks - which in my experience seem to be the most common nowdays),
or it can detect and throttle on attacker-IP and/or SPF (the MAIL FROM
addy domain not authorizing the attackers IP anyhow). 

The beauty of CBV to prevent dictionary attacks is that it's very hard
for zombies to work around - each zombie will need its own domain name
and DNS set up to point at its IP (unlikely, given the DHCP status of
most of these) and also an open server supporting a VMTA.

Kind Regards,
Chris Drake.