Re: IESG Statement on Spam Control on IETF Mailing Lists

On 2008-04-15 16:59 James Galvin said the following:
> 
> -- On Monday, April 14, 2008 10:25 PM +0200 Henrik Levkowetz 
> <henrik@levkowetz.com> wrote regarding Re: IESG Statement on Spam 
> Control on IETF Mailing Lists --
> 
>>> * IETF mailing lists MUST provide a mechanism for legitimate
>>> technical participants to determine if an attempt to post was
>>> dropped as apparent spam.
>> Again, an umm...  I'm not sure I'm aware of an available
>> technical solution which out-of-the-box will ensure this is
>> followed, without at the same time resulting in a deluge of
>> back-scatter.  If there was a SHOULD here, I could imagine
>> working over a bit of time at setting up Mailman to
>> drop-and-archive, but currently the solution which comes to mind
>> is to reject, which (I believe) potentially will result in
>> backscatter and more work and/or junk for the list admin.
> 
> There is another method, which is currently used on the IETF 
> mailing lists with a public archive.
> 
> First, the current statement does point you at the older statement:
> 
> <http://www.ietf.org/IESG/STATEMENTS/mail-submit-policy.txt>
> 
> Which says this:
> 
> 
> In other cases, it MUST be possible for the sender of a legitimate
> message, whether a mailing list subscriber or not, to determine if 
> it is has been dropped as apparent spam.  This can be done in 
> several ways; all of these have their advantages and disadvantages.
> 
>  b.  Provide an up-to-date archive of accepted postings.
>      Unfortunately, while this can show dropped messages, it doesn't
>      help if the email is merely delayed, nor does it say why a
>      message was dropped.  This MAY be used.

If this is acceptable, I'm happy.  Unfortunately, I wouldn't have
thought this solution would have been acceptable after reading the
statement of the original posting, and as long as the IESG doesn't
indicate that it is acceptable, I'll continue to be uncertain.

So as far as I can tell, the essence of my original response remains:

The original posting would have benefited greatly by including a
bit of rationale and examples; and my suggestion would be to do
any needed revision to the older statement:
  http://www.ietf.org/IESG/STATEMENTS/mail-submit-policy.txt
and issue a new version of that, which seems to give the background,
rationale and examples missing from the latest statement.  If the
latest statement is going to be allowed to stand, at least I am
going to feel that I'm guessing far more than I'm comfortable with
regarding exactly where the line between acceptable and non-acceptable
technical solutions to spam filtering goes.

If the IESG finds itself unable to find the time needed to revise the
older document I'm also offering to provide revised text based on
that document, in the interest of having policy I feel can be read,
understood and followed without too much ambiguity.

	Henrik
_______________________________________________
IETF mailing list
IETF@ietf.org
https://www.ietf.org/mailman/listinfo/ietf