Advertising the use of tagged bouce addresses
=============================================

$Cambridge: hermes/doc/antiforgery/advertising-batv.txt,v 1.1 2004/09/16 15:57:05 fanf2 Exp $


This document notes some considerations for extending the BATV
specification (for bounce address tags in the local part) and the BADT
specification (for bounce address tags in the domain part), which we
will refer to collectively as TBA (tagged bounce addresses). As they
stand, neither specification is a complete solution for preventing
envelope forgery: although they both allow a recipient to detect that
a bounce address is tagged, neither of them informs the recipient that
a bounce address should be tagged when it is not.

There are a number of ways that a recipient can find out that a bounce
address must be tagged:


SMTP callback verification

	CBV is a very useful technique even in the absence of TBA,
	though there are some interoperability problems with sending
	sites that are misconfigured such that they cannot receive
	bounces. However the major problem is that it is a fairly
	heavyweight protocol, because of traditional MTA
	implementation techniques and because of the load imposed by
	anti-spam defences. A site must have enough MTA capacity to
	deal with the load imposed by CBV, which scales according to
	the size of a spam attack rather than according to the site's
	legitimate traffic. Therefore it is disliked by heavily-forged
	sites, and cannot be recommended as an Internet-wide BCP.


SPF and Sender-ID/mailfrom

	These protocols have a powerful macro language which, in
	conjunction with a stunt DNS server (similar to that required
	for BADT), makes it possible to implement what is effectively
	callback verification over the DNS. This scales somewhat
	better than SMTP CBV because of the more lightweight
	implementation of DNS software, and the DNS already has to
	handle the full load of spam attacks: the cacheing
	infrastructure makes this easier. However we don't want to
	encourage the use of SPF since it comes with a heavy dose of
	designated sender braindamage; it's also excessively
	complicated.


TBA-specific protocol

	My original plan was to include in the BADT specification a
	simple method for advertising that BADT is being used by a
	domain and which local parts are using it. A related
	specification is draft-otis-marid-mpr-00, though that doesn't
	allow per-user policy variation. The main disadvantage of this
	approach is the probable unpopularity of checking by
	recipients.


With the latter two there is also an implementation difficulty. My
plan for implementing TBA verification in Exim is to rely on it to
resolve addresses to their final destination dynamically, which it
does anyway as part of normal verification. This means that the
additional TBA software doesn't need to know about email routing
through all the virtual domains, and can simply confine itself to
final message store addresses @hermes.cam.ac.uk.

In order to be able to properly advertise TBA usage we'd have to
perform the address resolution statically so that the results can be
published in the DNS. Or we'd have to re-implement Exim's routing in
the DNS server. Or we'd have to arrange for the DNS server to obtain
its result by performing an SMTP CBV to Exim, with the consequent
scaling limitations. None of these are particularly enticing.

In any case, the altruistic parts of the specification are the least
important, so this will be left aside for later consideration.

-- end --