Re: draft of Simple Junk Mail Declaration Protocol

David Nicol wrote:
> I have written a description of a simple protocol.  The front matter,
> back matter, abstract are missing.  It is available at
> 
> http://zarquon.advenge.com/RFCwiki/view?doc=AI
> 
> as well as appearing attached to this message.

I have one issue with this system:
The vast majority of users have not configured spam filters for themselves. 
If/when they upgrade MUAs to a version that supports this standard, there 
will not necessarily be a SJMDP-compliant filter working on their behalf, or 
even to their knowledge. Thus, spammers could add Is-Not-Junk headers to all 
outgoing messages, knowing that it will be treated as 'first class mail' by 
the MUAs of people who aren't filtering for themselves.
On the other hand, these users are probably signed up with large ISPs that 
do filter aggressively, so it may not be such an issue.

Also, many ISPs will not facilitate users 'opting out' of filtering at the 
ISP in favor of an upstream forwarding address. If a formerly non-using ISP 
installed a SJMDP system one day, there would be no indication to end users 
that the results are coming from a different source.

Finally, there's also the problem of (potential lack of) authentication. 
It's trivial to authenticate that the headers were written by the last 
compliant MTA the message went through. However, this isn't particularly 
helpful, because there doesn't seem to be anything indicating which MTA that 
was.

Here's how it compares to a more general Filtered header:
1. Programming generation/insertion
SJMDP - strip existing, insert fixed string (maybe generate part)
Filtered - Insert generated/composed string in trace field position
So the cost tradeoff is finding and stripping the existing headers versus 
building the new header.
2. Programmatically interpreting results
SJMDP - search for Is-[Not-]Junk headers
Filtered - read all such headers (or stop after certain distance from top), 
decide which ones to trust (whatever desired algorithm, from presence to 
crypto-signature), parse for desired information
Tradeoff is more time processing for more information gotten
3. Range of possible results
SJMDP - yes or no
Filtered - # possible classifications * range of confidence values
Do we want restricted, single use, or do we want open-ended, extensible use?
4. Information conveyed to end recipient
SJMDP - does some system think this is or isn't junk?
Filtered - At time T, software S (of version V) on host H determined this to 
match classification C with confidence X
What do users really want/need?
5. Authenticity of information
SJMDP - if user has knowledge of the last compliant system in the MTS, 
guaranteed. Otherwise, basically no guarantee
Filtered - guaranteed insertion after fixed points in time/network. Can 
easily be extended to strong cryptographic protection
I can see someone saying "I don't care who said this was spam, but I know 
someone did". However, that doesn't mean such an attitude should be written 
into a standard.

This makes for a good contrast. Thanks.

Sincerely,
Philip Miller