On Tue, Apr 24, at 02:13 Jeremy Huntwork wrote:
> On Mon, Apr 23, 2007 at 08:46:04AM +0300, Ag. D. Hatzimanikas wrote:
> > Maybe it's a flaw in Track, maybe there is already a patch.
>
> Keep in mind that, although it may have appeared that way externally,
> the idea to try out greylisting had nothing to do with recent vandalism
> of the trac system(s). We fully realize that there are two separate and
> distinct issues there.
>
Alright then, although I didn't notice any spam in mailing lists in the
last year, since we started to require registration for posting.
Anyway my main concerns were/are the followings:
By rejecting mail and adding overhead to the mail server of the sender,
is not considering - in my poor opinion - civil/social behavior.
Since I started to reply to you, I read/thought a little about it and
gathered some information which I will share for reference.
The logic behind greylisting is rejecting email with a temporary error
code -- which is defined in RFC 821 [1] and should be honored by the
moderns MTA's-- so:
- Any "well behaved" [2] MTA will try to resend the email, which is
exactly what we want.
But the 450 code is described as: User not active now.
Isn't this (when with our software return 450) some kind of a violation?
Personally I would like an answer about that, because quite
possible, as a novice in these matters, I'm missing something.
- The spam software will see the error code (450) and quite possible
will not try to resend the email, considering as a dead connection.
Smart for a start, although spamers can be smart too and soon or
later they will make adjustments to their software.
Probable using another domain for their host to resend their spam.
Thus, it means extra resources for them, but also means extra
resources for us too and for all the networks out there extra
traffic.
Should networks be penalized in the fight against spam? [borrow the
question]
- The first delay delivery. We've had already some cases:
http://linuxfromscratch.org/pipermail/lfs-support/2007-April/033010.html
And I remember there was another one.
So before the users start and complain and make our service looks
unreliable, and if we decided to go that route, we have to warning them
for the delay.
With which way is up to you. For sure, with a warning in the web page.
As an extra measure, and for debugging reasons, maybe it's good to add
another header like: "X-delay" or something -- which will tell us the
exact time of the delay, if this is possible.
I have to say though, that there is a benefit from that procedure.
Most anti-spam software make extra usage of the system resources, so by
reducing
a good amount of spam with greylisting (hopefully), and freeing some system
resources, we can make a more extensive and careful filtering by the
traditional
anti-spam software.
For example.
I've had many rejections (at least 4-5) in the past, when the email was
too long.
I want to make a request for those who have the rights to do so, and:
a. Have a second look to the filters and
b. To have a clear notice in the web site, where we can find an email
address, of who (1 or 2 or 10) will be responsible for the job.
So addressing problems like this (rejection of a legitimate email)
will be easier.
[1] http://www.faqs.org/rfcs/rfc821.html
[2] http://projects.puremagic.com/greylisting/whitepaper.html
--
http://linuxfromscratch.org/mailman/listinfo/lfs-dev
FAQ: http://www.linuxfromscratch.org/faq/
Unsubscribe: See the above information page
