Re: IESG Statement on Spam Control on IETF Mailing Lists

[Cullen Jennings <[e-mail]>]

Hi Henrik,

Seems this email about email still needs some more discussion - I have  
not been involved much with this much but I suspect that Chris Newman  
would probably be the best person on the IESG to work with on both  
clarifications and changes.

Cullen

On Apr 15, 2008, at 10:49 AM, Henrik Levkowetz wrote:
>
> On 2008-04-15 16:59 James Galvin said the following:
> >
> > -- On Monday, April 14, 2008 10:25 PM +0200 Henrik Levkowetz
> > <[e-mail]> 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
[e-mail]
https://www.ietf.org/mailman/listinfo/ietf