Re: draft of Simple Junk Mail Declaration Protocol

Point-by-point response.


Philip Miller wrote:
> 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.

I take this to mean that the SJMDP document could contain a section
in the bit or reccomended MUA design that says the junk/not-junk button
should fall back to an internal bayesian system until configured.  Also
a possibility that POP3 and IMAP could be extended to have a mechanism
in them that says "This system is SJMDP-conformant" to keep the
configuration level low.

Or we could reccomend that MUA software that notices a consistent
mismatch between SJMDP-report and internal bayesian score merely use
SJMDP value as just another piece of information.

I had to turn the junk/not-junk button in Thunderbird on before it
worked. Adding a "respect SJMDP headers" button in the junk button
configuration is pretty much what I had in mind, and exactly
what degrees of full/partial/none would be made available are
outside the current reach of my crystal ball.

> 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.

I expect the ISP would announce the upgrade through their normal
channels through which they communicate with their customers.  The
admins of Shared Designation Engines currently installed in offices
certainly have channels available to them.

> 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.

We don't care.  A conformant system clobbers preexisting declarations
and replaces with its own.  I suppose I may have silently presumed that
SJMDP would be appropriate where the MTA and the final hop MDA are under
the same management.  Does this need to be spelled out further?

> 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?

also, SJMDP includes facility for indicating back to that system
whether the final recipient agrees with the designation.

> Filtered - At time T, software S (of version V) on host H determined 
> this to match classification C with confidence X

This information is currently available by extended headers, through
which vendors of external message analyzers communicate them currently.
What advantage does *having a standard* give?  The disadvantage -- a
standard way to spoof -- is clear.  It seems to me that the
information that at time T, software S (of version V) on host H
determined a message to match classification C with confidence X is
better hidden in an obscure and site-specific encoding and the
advantage of standardizing this is not clear.

Unless the scenario the Filtered header is supposed to support is
internal between trusted advisors and a junk decision system.

If e-mail system E uses a shared designation engine and gets
opinions from several different content analyzers before arriving
at a designation, an architecture other than SMTP and addition of
headers would work just as well, or even better.

Or is the point of the Filtered standard an encoding for C and X
that can be incorporated into message filing rules using sliding
scales in new MUA software and recognized as sliding scales
by cognizant future Beyesian systems?

> What do users really want/need?

Maybe we could issue two reccomendations for the two scenarios.


> 5. Authenticity of information
> SJMDP - if user has knowledge of the last compliant system in the MTS, 
> guaranteed. Otherwise, basically no guarantee

when receiving mail from a compliant system, it works, otherwise it
doesn't.  <frown> My MUA doesn't suddenly randomly download incoming
e-mail from unknown POP servers.  Does yours? </frown>  The SJMDP
configuration would be a per-account setting on a multiple-account MUA.


> 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


SJMDP also has some focus on operability with current MUA software.
There is no option for comparing time stamps between two headers in
the message filing rules creation editing interface on any GUI MUA
I've ever used, although I am sure adding such a rule to procmail
would be relatively easy.

Like I've said before, I believe the reason we're here, working at
this project, is to accomodate the shared designation engine scenario,
and not anything else.

The Filtered header, by itself, is only half of the SDE scenario.

It seems like implementing recognition of the Miller Filtered Header
would imply embedding a considerable programming language into
filing rule parsing engines.


Thanks for your comments.


My question is, if we're not trying to facilitate shared designation
engines, what are we doing? And I think I answered that above, at
least I gave a guess.

There are several points to list in a MUA Implementation Considerations
section, I'll try to add that.






-- 
[email protected]
"There's a fine line between participation and mockery" -- Scott Adams