"Douglas" == Douglas Otis <dotis(_at_)mail-abuse(_dot_)org> writes:
This will be my last post on this topic. I think I've made my points
as clearly as I can; beyond that we'll just have to agree to differ.
I think this seems to be intended as a reply to me, rather than a
reply to Terry, so I'll reply to it.
Douglas> This Back-door issue will improve commensurate with
Douglas> adoption of a solution, as spammers are not often the
Douglas> direct source of this traffic, but instead comes from
Douglas> sites at the end of a relay that would otherwise not wish
Douglas> to send this traffic.
I'm not really sure I know what you mean by 'back door', 'front door'
and 'at the end of a relay'.
Although mail may transit many MTAs, most mail typically goes directly
from a final outbound MTA in the originating administrative domain to
an initial inbound MTA at the receiving adminsitrative domain. Either
the outbound administrative domain implements checks on outgoing mail,
or unwanted/invalid mail will be rejected by the MTA in the
recipient's adminitrative domain, causing the outbound MTA to generate
a bounce.
This property is common to _all_ solutions that mandate or suggest
rejecting unwanted messages at the SMTP level. To my knowledge, all
proposals on the table allow SMTP rejection, and as far as I can see
their behaviour with respect to backscatter will be very similar.
Douglas> Few solutions have an impact that exceeds adoption. That
Douglas> a solution does not TOTALLY prevent a problem without
Douglas> 100% adoption and therefore is a reason to dismiss such
Douglas> for consideration seems absurd.
I'm not arguing that. I'm arguing that even a MARID solution that
validates MAIL FROM (such as SPF) is unlikely to have _any_
significant affect on the backscatter problem until it reaches _very_
high levels of adoption. More to the point, it needs adoption on ISPs
outbound relays, and at the moment interest seems to be more in
validating _incoming_ mail.
Douglas> To say this is an unrelated problem, or one to be solved
Douglas> differently, seems to overlook the relationship of the
Douglas> information needed to solve each issue separately.
Well, I believe largely it is. IME the main cause of backscatter is
bounces due to spam or viruses sent to addresses that no longer exist
(resulting in 550 User Unknown).
In many cases the inbound relay in the receiving administrative domain
rejects the message with 550, resulting in the outbound relay of the
origninating administrative domain generating a bounce.
However, in a large number of cases the bounce is actually generated
by the receiving administrative domain _after_ the message has been
accepted by the initial inbound relay.
There are two main reasons why this happens (and whether you like it
or not, this isn't going to change any time soon).
The first is that the architecture of some widely used MTAs doesn't
allow them to perform SMTP-time checks for unknown users. qmail and
Lotus Notes spring to mind. qmail is widely used by ISPs, and Lotus
Notes has significant adoption in large corporates.
The second is the design of large mail clusters is ISPs or complex
mail routing environments in large corporates. In many cases the
initial inbound relay doesn't know that the validity of the address,
but simply forwards the message to other internal MTAs based on the
domain (or subdomain). Hence, when a 550 User Unknown is generated,
it's the receiving domain that's forced to generate a bounce
(regardless of the choice of MTA software).
So yes, I think that the backscatter problem is largely unrelated to
the work we are doing here. Some solutions may make the problem
marginally worse; some may even make things very marginally better
(though I'm dubious).
The only things that will make things substantially better are either
mandatory checks on outbound mail from all (or the majority) or ISPs,
or solutions where the bounce is validated by the recipient (such as
BATV, SES, Message-ID tracking schemes, etc).
I don't think the former will happen quickly enough to prevent
widespread adoption of the latter.
-roy