Re: ML improvement proposition (Re: SMTP 550 on replies to bugs)
* 18-09-2007, Bernd Zeimetz
* User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.8.1.4) Gecko/20070828 Thunderbird/2.0.0.4 Mnenhy/0.7.5.0
>
>> * Allow messages, that have "In-reply-to" and "References" with valid
>> message-id's (SHOULD in rfc2822) to pass to bts/ml freely.
>
> Why? This can be faked easily, getting them together with a destination
> email address should be pretty easy for spammers.
[^]
>> - in case of `smart' spam, i.e. real spam with valid "In-reply-to" and
>> stuff, blacklist smart spammers.
>
> LOL. Do you REALLY think that those spammers are so stupid that they
> wouldn't start to grab message IDs as soon as they see that this
> blocking function is integrated?
I accept, that all idea can fall apart, iff smart spammers really exist.
This is matter of scientific experimentation, rather than hand-waving,
right? Even if i'll enforce sub-subject matching, i.e. things like
/Re: \1/
/[^(]*(was \1)/
is it imaginable, that such kind of very comprehensive spam will emerge?
If smart-spammers will be so clever (and nice :) to implement that, then
OK, blacklist is a good reward for that.
>> * Opening new threads in MLs requires a ticket.
>>
>> - ticket is a message (can be in the 550 error text, btw)
>> that shows what must be put in "In-reply-to" to have thread opened,
>
> which is not understood by users or just thrown away because it's
> annoying, or users just don't read it because they think that the BTS is
> broken and stop taking care of the bugreport.
Well, i'd said developers in first place. Spam in debbugs, bts (for
existing bugIDs) is just isn't handled on some week days at all.
For users, i don't know, what is better:
* 550 with bounced message with "Read FAQ, use google/archive, get a ticket"
* Another quick and silly question.
>> - ordinary spam filtering may be applied to the first message even
>> with valid ticket,
>
> why use tickets at all then?
...
>> * In case of slowness of validating message ids due to huge amount of
>> them, limit archive time of threads to 3 or 4 months. Error message
>> in 550 this time must be "open new thread, please". OTOH, Gmane
>> operates the load, that's times bigger, that any debian's ML or even
>> whole lists. And this is only one `inn`, if i understand this correctly.
>
> So you don't want to allow people to reply to old threads?
...in case of performance penalties. Was i unclear in that paragraph?
>> * It brings threading to mails in BTS automatically. If people
>> don't reply to messages, that already are there, it's spam or misuse
>> of e-mail.
>
> not really. Ever used the 'bts'-tool? Or cat to write your mails because
> you're on some shell on a re mote server and don't want to setup mutt?
> Validating to every message is just pain to do, and probably you can't
> even reply to them because all you have is a remote shell on a (due to a
> bug) broken machine.
Well, i have text only environment set up no problems with scripting, os
hacking. In any case, all you've wrote from your Mozilla is just
additional `echo "Message-Id: $1"` to SMTP posting script, everyone might
already wrote for such cases.
> If you don't want to have mails at all, use some kind of validation
> before you receive a mail. Your theories may work for your personal
> inbox, but neither for MLs nor for the BTS.
I was addressing issues with low man power in help for listmasters and
spam waves in development lists i (and many others) read. CPU power
wastes by extensive technologies, like current spam filtering.
> YMMV.
> --
MMA, BTW is about a year, so far nothing really huge happened in my
inbox. Even though debian's lists and bts have plain text archives.
> Bernd Zeimetz
> <bernd@bzed.de> <http://bzed.de/>
_____
Reply to: