Jay,
As far as how to configure Alligate, I think that it would be better to
discuss this off-list or on the product's own list, but to give a brief
answer to your questions, almost all functionality is exposed in the
GUI, but there are some undocumented things additionally that may be of
use and possibly some things that aren't yet enabled in the released
product yet. The interface is a bit confusing since it has it's own
language and style of approaching things. In short, you can achieve the
virtually same results as I did at the gateway level with what is
available now, but you have the ability to tweak the settings whatever
way you wish according to your own standards.
Matt
Jay Sudowski - Handy Networks LLC wrote:
Hi Matt -
I am still somewhat confused because you are painting a rather broad picture
about your success with Alligate, and not really getting down to the nitty
gritty specifics. I can appreciate that you may not want to disclose your
exact configuration. However, I can't even figure out if all of the things
you're talking about are available in a stock edition of Alligate with the
MXRate subscription, or if you've extended the functionality of Alligate in
ways that are specific to your installation, using tools or features that I
won't have access to.
http://www.alligate.com/help/AdvGreyOptions.htm -> this seems to be the case
specific greylisting you're talking about ...
http://www.alligate.com/help/blocking.htm -> has some tarpitting options ...
Even so, I am still pretty confused about this. Any clarification would be
appreciated.
Thanks!
-----
Jay Sudowski // Handy Networks LLC
Director of Technical Operations
Providing Shared, Reseller, Semi Managed and Fully Managed Windows 2003 Hosting
Solutions
Tel: 877-70 HANDY x882 | Fax: 888-300-2FAX
www.handynetworks.com
________________________________________
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Matt
Sent: Thursday, May 25, 2006 6:16 PM
To: [email protected]
Subject: Re: [Declude.JunkMail] Experience with 4.x
Pieced below:
Jay Sudowski - Handy Networks LLC wrote:
I am contemplating implementing Alligate with SmarterMail in some fashion, and would like to pick your mind on the following:
1) SmarterMail does a great, great job at handling a huge number of SMTP
threads so dictionary attacks are not really an issue. We have popped up to
2000 SMTP threads without incident. And since addresses being attacked do not
exist, the messages get rejected with a 550 error, connection is closed and
there's no real strain on the server (at least in terms of I/O) -- do we get
any benefit from putting Alligate in front of SmarterMail for dictionary attack
prevention?
Definitely. Not all dictionary attacks hit completely bad addresses, but detecting and stopping an should be rare if you configure it carefully.
2) Does SMTP AUTH pass-through and recipient verification actually work, all
the time?
I don't use this since it is not necessary to do so for pre-scanning purposes. This is really designed to take the load off of a hosted mail server by off-loading this traffic. I can't say personally that it works perfectly, but I'm sure that it does. Other pass-through verification stuff that it does definitely works, and works efficiently.
3) I see greylisting as the real area that could benefit us -- we would avoid a
lot of the zombie spam by implementing greylisting, and that would save us tons
of resources all around. However, I understand that some zombies are now
greylist aware and will retry.
Greylisting is huge, but it has fundamental problems that kept me from using it in vanilla form with ORF. I know that Nick used it with ORF and backed off. My big issues are two-fold. By arbitrarily applying greylisting to everyone, you will effectively block E-mail from sending software that doesn't spool (and zombie spamware isn't the only thing with that limitation). It's things like blackboxes and other forms of notification programming that lacks such functionality and can fail greylisting, at least for the first message. Some bulk mail (ecommerce and otherwise) will only send once, or may requeue and send through a different IP subsequently causing delivery failures or long delays. Even more important to me is the fact that greylisting causing issues with delaying legitimate E-mail, and I refused to implement it in ORF solely for this reason. It's not acceptable for the class of service that I want to offer. I want E-mail to pass through our system in less than 5 seconds except in extreme circumstances.
I fed Brian a framework for doing what I call "selective greylisting" which
resolves these issues. Essentially it only greylists when conditions warrant, and the
only drawback is greylisting poorly configured hosts or some that leak spam (but not all
of either). It works so well that there is no reason to have it do full greylisting. I
won't go into the details of how this is done here because to some extent I consider it
to be intellectual property. Also note that Brian isn't just a coding monkey, and he
contributed a lot to the end product and filled in many gaps. There are also advanced
tarpitting techniques that cause almost as many failures as greylisting does because some
spamware detects tarpitting and disconnect, but it is variable according to when and how
long it occurs. The last major piece is the MXRate functionality, and it blocks a lot
even when limited to just 100% hits (which surely aren't perfect, but they are very near
perfect).
While I don't feel like running DLAnalyzer, we typically trend about 85% of
email is spam that gets deleted before it's delivered, which means we probably
had around 40,000 actual deliveries. If we can eliminate 50% of the spam using
MXRate and greylisting, that is a huge burden off of declude and the server in
general.
I block 99.9% of all spam and our false positive rate is less than 1 in 10,000, with most of that being some form of advertising sent from hosts that also send for dirty lists, and most don't care about such things. Most of our issues with personal E-mail are the result of foreign traffic, especially with China. Alligate certainly helps since it eliminates almost all zombies and viruses, but it also stops some static spammers as well, but Declude is still of course critical, and so is Sniffer and Eradispam, as well as some of my own programming. My stats are accurate since they are based on manual review in repeated circumstances. We also hold less than 1% of blocked E-mail for review making the task easy, and therefore false positives are more readily found.
Out of the net 288,842 messages that our gateway blocked, only 40,137 of >them
received permanent 550 errors not related directly to bad recipients. >All of the
others were blocked by methods that are more passive in nature >and designed to
exploit weaknesses of spamware.
Is this a reference to greylisting or some other feature in Alligate I'm not
seeing?
I described the main techniques above. It is a combination of address validation, tarpitting, greylisting and MXRate, but not all address validation, tarpitting, and greylisting is created equally. I have never seen anyone else even talk about selective greylisting for instance, and I'm so damn grateful that I now have it. The devil is in the details though, and even not all Alligate setups will achieve such results with such accuracy just like Declude setups.
Please also note that Brian once was bashed here for promoting his product
while in beta, and I'm sure that I might be pissing a few off by talking about
it, but I have tried to steer away from talk of Alligate outside of mentions
except for where people ask since I believe it is valuable information and that
is why we are here. Declude could easily plug into Alligate if they wanted to
since it supports dropping files into a directory instead of delivering them,
and then it will pick them up when the external app is done. I would love to
see that happen since I only need IMail as a container for Declude. If there
is still a widespread adversion to this discussion, I would be happy to take it
off-list.
Matt
---
This E-mail came from the Declude.JunkMail mailing list. To
unsubscribe, just send an E-mail to [EMAIL PROTECTED], and
type "unsubscribe Declude.JunkMail". The archives can be found
at http://www.mail-archive.com.
---
This E-mail came from the Declude.JunkMail mailing list. To
unsubscribe, just send an E-mail to [EMAIL PROTECTED], and
type "unsubscribe Declude.JunkMail". The archives can be found
at http://www.mail-archive.com.
