From: "Raymie Stata" <raymie(_at_)cs(_dot_)ucsc(_dot_)edu>
Reply-To: "Raymie Stata" <raymie(_at_)cs(_dot_)ucsc(_dot_)edu>
Date: Wed, 5 Mar 2003 00:39:25 -0800
Subject: [Asrg] Requirements for source tracking
<snip>
Here are a few opinions:
* Message vs. envelope sender.
I think the focus should be on message sender and/or domain, not the
envelope sender/domain. At first glance, the envelope sender/domain
appears to have practical advantages over the message sender/domain,
but at closer inspection I think these disappear (anyone disagree?).
On the flip side, the message domain/sender is what the USER sees (and
is what most filtering software uses), so it seems like this is what
should be subjected to tracing. (This seems contrary to the schemes
I've seen posted so far, which seem to focus on the envelope sender
and/or domain.)
I think you may run into problems as soon as you start looking at content;
RFC821 (or sucessors) is not restricted to transferring content encoded
using RFC822 (or successors). For example, a secure email system might
choose to encrypt the whole of the content as provided by the originator
(not Recived-From: headers, which could be prefixed unencrypted, as they are
not provided by the originator) which means nothing other than the sending
and receiving MUAs can see the From: header (if there is one), so the
message with untrackable source can't be chopped off close to source and
continues to waste bandwidth and to delay download of non-spam email at the
receiving MUA (since it has to be downloaded and encrypted before the From:
header is known to be fake). So tracing the Mail_From: domain may not be
the best basis for attacking spam. The same applies to content-filter based
solutions, of course. I don't think this is an insuperable objection to
basing things on the From: header but you do need to look at all the
consequences of doing so.
Another problem is that authentication of From: headers requires change in
the sending MUA (as does useful authentication of the envelope sender too);
authenticating the trail of MTAs doesn't require change in the sending MUA.
SInce it will take years for a protocol extension to spread around the
internet, and we can be sure that spammers will not adopt the extension in
their sending MUAs until the take-up is very high amongst users, might it
not be better to go for trail authentication?
* Advocates of DNS-mapping approaches (appear to) claim that this
approach requires less change to existing infrastructure than do
cryptographic approaches. I question this claim. The DNS-mapping
schemes I've seen all involve adding new records to a domain's DNS
record-set. Of course, DNS can be used to distribute keys as well
as addresses, so it seems like a cryptographic scheme could be built
with exactly the same amount of change required by a DNS-mapping
scheme (viz., the addition of DNS records).
This is obviously correct, and adding key records strikes me as more likely
to be useful than the other suggested additions. I'm still inclined to
distrust anything DNS-based though (although I can't think of a better way
of distributing such a massive set of public keys).
Having the keys available would be useful for envelope sendeer
authentication as much as for message sender authentication; equally for
trail authentication (each MTA signs the Received-From: header that ut
inserts). I would prefer to see all three things authenticated together -
this can sometimes help when a key has been compromised - to be as sure as
possible of identifying the spammer.
_______________________________________________
Asrg mailing list
Asrg(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/asrg