Erik Espinoza wrote:
Hey Eric,
The drawbacks are not correct, here are more to go with what you have.
I believe the drawbacks I listed are correct. Which one is not?
I didn't intend my list to be exhaustive, however I did unintentionally
omit the one about server farms.
- Typical retry after soft rejection for most smtp servers is 4 hrs,
so one will wait 4 hrs for every e-mail to be delivered.
Not according what I've read.
If the parameter for waiting (recommended 1 hour) is reduced to as
little as 10 seconds (I think I'd try 30-60 seconds), then the wait is
reduced to an acceptable period, typically only a few minutes. Note,
this applies only to the first email for the triplet. All subsequent
email suffers no delay (other than looking up the triplet in the database).
- False positives generated by: Novell Groupwise 6.0, ISMail 1.7.1 and
prior, InterMail 4.0, Kerio MailServer 5.0.5
I didn't come across any references to this. Will you point one out so I
can look into it?
- Mail may get dropped if trifecta isn't matched (ip address, sender
address, recipient address). This happens a lot on big isps that that
have multiple outgoing mail servers. (AOL, Gmail, Hotmail, Yahoo!,
etc).
These mailers can easily be whitelisted.
- Troubleshooting nightmare for newbie users (face it, a big chunk of
the QmailToaster audience has trouble installing the QmailToaster, I
can only imagine what soft rejecting all incoming mail is going to do
to this poor list . . .)
There are indeed troubleshooting issues with the toaster as it is,
particularly the fact that messages are bounced with no log messages. I
find that to be a major deficiency.
These troubleshooting issues should certainly be addressed, and perhaps
with a higher priority than greylisting, but they should not be used as
an excuse for not adding desirable features.
I strongly oppose Greylisting, but I think I've made myself clear.
You may, and you have. Just because greylisting might be available
doesn't mean you have to use it. If it weren't tailorable, I'd be
opposed to it too. However, there might be others of us who would like
it to be included in the toaster. One size does not fit all. I think it
would be a valuable feature to have in the toaster.
I'll be waiting to see what J/N think about it.
Thanks for your input. I hope this doesn't cause any contention.
Thanks,
Erik
On 7/16/06, Eric Shubes <[EMAIL PROTECTED]> wrote:
Thanks to Erik for pointing me in the right direction and getting me
started on this. I don't know if this will materialize or not, but
here's what I've found to this point.
Greylisting has reportedly had much success in the spam war. There are
benefits, but there are also drawbacks. There are many web references
which discuss the situation. Here is a brief summary:
Benefits:
.) spam is rejected at the smtp layer, which translates into substantial
savings in bandwidth and server resources (load)
.) very high rate of rejection (at least for now)
.) little impact on users and administrators to implement
.) no false positives
Drawbacks (summary):
.) delay in receiving first-time correspondence
.) first-time becomes every-time for some list mailers, ezmlm in
particular
.) all mail servers in a domain must implement greylisting for it to be
effective
While greylisting is not a replacement for existing spam fighting tools,
it's a nice addition to the arsenal and makes some existing tools more
effective. While the drawbacks are considerable, there are ways of
dealing with them that are manageable. I've concluded that I'd like to
see greylisting as a feature of the Toaster.
I proceeded to search for existing greylist software that would fit well
in the Toaster. There are a lot of solutions available (I won't go into
details here), but only one that I thing might fit well with the
Toaster. It's available from Bill Shupp (http://www.shupp.org), who made
the qmail and clamav patches.
Bill notes on his website that this patch is EXPERIMENTAL. Has anyone
here experimented with it at all? Is there any reason why we (I?)
shouldn't give it a try?
I also found a nice additional patch at http://www.dewmill.com/qmail.html
which apparently allows for per-user control of virus scanning,
greylisting, and acceptable recepients. I'd like to see this patch added
in conjunction with greylisting. It would allow for easier phased-in
implementation of greylisting, while providing other per-user tailoring
as well.
Erik mentioned previously that most qmail greylisting patches do not
work properly in conjunction with smtp-auth. Does anyone know if this
also the case or not with these patches?
I'm interested to know what anyone thinks of this (especially J/E/N). I
don't want to delve further into this without some sort of group
consensus. TIA for your input.
P.S. The problem with ezmlm will be taken up later in a separate thread.
It may or may not still be a concern, but has no bearing on implementing
greylisting with qmail (the toaster).
--
-Eric 'shubes'
--
-Eric 'shubes'
---------------------------------------------------------------------
QmailToaster hosted by: VR Hosted <http://www.vr.org>
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
