Re: [anti-spam-wg@localhost] it could be sooo easy - Solution to Spam
- Date: Fri, 27 Jun 2003 05:55:21 -0400 (EDT)
> Here are three approaches using the DNS to document outbound mail
> servers for a domain:
> Jim Miller / Paul Vixie
> http://ops.ietf.org/lists/namedroppers/namedroppers.2002/msg00658.html
This suffers from the big-packet problem, the problem that a domain
with a lot of valid outgoing mailservers must return a huge response.
It also suffers from the "overloading" problem, in that it takes an
existing record with well-defined existing semantics and makes it mean
something else, without isolating those changes in a part of the DNS
tree where they couldn't normally be. (This latter is easy to fix, by
changing the mail-from constant into something not legal for mail, like
_mail-from.)
It also suffers from the broken-forwarding problem, the problem that
many currently normal means of forwarding mail (such as traditional
.forward files) do not rewrite the envelope sender and hence cause mail
to be emitted from hosts that do not normally send mail with that
envelope sender domain.
> You might want to have a look at these drafts:
> Gordon Fecyk "Designated Mailers Protocol" (DMP):
> (Home: http://www.pan-am.ca/draft-fecyk-dsprotocol-02.txt )
This does not suffer from the big-packet problem or overloading
problem. It does suffer from the broken-forwarding problem. It also
has problems with DNS wildcards (the wildcards specified are not
sufficient to get the desired behaviour from spec-conforming DNS
servers, though at least two DNS servers are known to produce the
behaviour DMP wants rather than the behaviour required by the spec); it
needs to be rewritten in terms of what a querent sees instead of in
terms of how that is specified in the sending domain's zone file.
> Hadmut Danisch "DNS RMX RR"
> http://www.ietf.org/internet-drafts/draft-danisch-dns-rr-smtp-02.txt
This suffers from the big-packet problem. It attempts to help it
somewhat by permitting CIDR masks, but that's no help unless all the
relevant mailservers are concentrated in a CIDR block, with no
non-mailer hosts.
It does not suffer from the overloading problem, but suffers from
something arguably worse; it demands that DNS software (server and
client both) be updated to understand the new record type.
Since it is driven off envelope sender domains, it suffers from the
broken-forwarding problem.
Contrast this to Markus's suggestion, which does not suffer from any of
these problems (big-packet, overloading, new-DNS-software, or
broken-forwarding), at the price of being weaker (mailer or non-mailer,
without any indication of what domain(s) mailers are for).
In my eyes, Markus's suggestion is the best of the lot. If adopted it
would cure much of the present spam problem (stemming the flood from
open proxies and 0wn3d machines - it's not my preferred method for
curing them, but my preferred method simply will never be adopted, and
I'm not so unrealistic as to think otherwise). It would not stop
mainsleazers or dedicated spamhauser, but they are relatively easy to
identify and block, either by domain name or IP - and none of the above
proposals would stop them either.
/~\ The ASCII der Mouse
\ / Ribbon Campaign
X Against HTML mouse@localhost
/ \ Email! 7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B
