On 2/8/2010 12:56 PM, Andrew Richards wrote:
That creates a massive barrier to adoption. Huge implementation
overhead.
However TiS is implemented will require implementation work on the server-
side, so I'm not sure that [2] is so different from [1] in this respect.
The nature and amount of change on the server sides depends on quite a few
things.
Certainly there needs to be software at the reporting mailbox, to process
reports. That's a fixed requirement and it's outside the scope of the current
discussion.
What remains is differential cost, security and efficacy choices for signaling
the reporting address to the MUA.
The DNS approach will tend to be somewhere between free and cheap for mainstream
uses.
The message-header-field approach is probably pretty cheap, but introduces trust
concerns. It might also have a per-protocol server cost, depending on whether
it's possible to affix the header before the retrieval protocol server comes
into play.
The in-protocol approach is probably relatively cheap, but definitely has a
per-retrieval protocol cost.
None of these have the kind of synchronization issues your proposal calls for.
while no doubt true, it is not a clear to me that it's appropriate to
make it impossible to submit older reports.
MTA admins may choose how long to retain copies of messages, perhaps
subject to a suggested minimum. So yes it would be impossible in some
cases, but is that a problem if 95% of spam can be successfully reported
You are making an assumption and validating it requires empirical data. I
haven't seen any. Unless you have, the 5% you cite is merely a measure of your
hope, not a measure of what we can expect to be true. In addition, the fact
that the design guarantees that there is /some/ time limit is a design
limitation worth worrying aobut.
d/
--
Dave Crocker
Brandenburg InternetWorking
bbiw.net
_______________________________________________
Asrg mailing list
Asrg(_at_)irtf(_dot_)org
http://www.irtf.org/mailman/listinfo/asrg