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 > > <henrik@xxxxxxxxxxxxx> 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@xxxxxxxx https://www.ietf.org/mailman/listinfo/ietf