"Harry Katz" <hkatz(_at_)exchange(_dot_)microsoft(_dot_)com> writes:
On Monday, August 09, 2004 10:24 AM ned(_dot_)freed(_at_)mrochek(_dot_)com
wrote:
First, I am not proposing anything here. Not only is
SUBMITTER not my idea, I have been quite clear that I am
ambivalent about its inclusion in MARID.
Second, the optimization in case 1 isn't a failure case but a
success case.
There may be a throughput improvement in some MTAs if the
check can be done sooner. Mind you, I'm not saying there is
guaranteed to be such an improvement
- just that it is a possibility. Actual implementation
experience would be needed to tell for sure.
Ned is exactly correct here. The purpose of SUBMITTER is to allow early
(i.e. at 2821-time) verification of the sender's identity, namely the
PRA. At the IETF meetings last week there was some discussion of
whether this would result in bandwidth saving, throughput improvement,
or no benefit at all. I tend to think there will be modest throughput
improvement, but agree with Ned that we need to verify through testing.
The issue that I have here is that the optimization is
misplaced engineering at best, and possibly the victim
of unintended consequences at worst. The ultimate
optimization is for spammers to not send _any_ packets at
all. One thing that we know is that if we close off one
avenue, spammers will shift their attention to other lines
of attack. Thus if the base level check prevents forgery,
they'll switch to a line of attack that doesn't use
forgery. Creating a lot of infrastructure to optimize for
a likely deprecated behavior doesn't strike me as an
especially worthwhile use of engineering resources.
On the harmful front, I have lingering doubts and worry a
lot about what the consequences for mischief of
introducing yet another identity -- and what exactly it
means. I don't think we should take that lightly; if it
has utility on its *own* merits, fine, but as currently
instantiated as an optimization for MARID, it seems rather
useless since spammers will simply never use this
extension.
--
Michael Thomas (mike(_at_)mtcc(_dot_)com http://www.mtcc.com/~mike/)