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(_at_)levkowetz(_dot_)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(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf