Hello Tony,
(See answer below, quote left in for completeness...)
Saturday, February 18, 2006, 1:57:58 AM, you wrote:
> I am testing Davide's greylist module (as usual - very nice), but have one
> question. It seems that the sender always receives 1 bounce message when
> greylisting is activated.
> I would really like the process transparent to the end user - for the sender
> to not receive any notice. I thought that the NotifyTryPattern might help,
> but it doesnt seem to stop the initial (transient) bounce message. Maybe
> I'm missing something - or the point of greylisting - Am I making sense to
> anyone?
> Have I missed the simple way to stop the initial bounce message?
> Tony
Ok, let me try to explain this with a long winded run-in...
Gray-listing works as follows:
Sender contacts destination machine.
GLST checks to see if this triplet (IP, From, To) has been seen,
longer than x (as defined per config, in my case 10 minutes.) time ago.
If yes, then allow message to go onto next step.
If No, then tell sender server to back of, with a 45x message.
Now, normal servers will re-queue the message, but spammers tend to try
and try again, which normally is within the time-out window, so they
don't succeed.
So, if you get a bounce message on the first attempt, as it has not
entered the server yet, this bounce message would be generated on the
sending machine, by the reject from the destination server. Therefore,
"NotifyTryPattern" is only valid, once the message is in the XMail
queue, which isn't the case as it has been temporarily "rejected".
(Read "told to back-off"...)
This obviously would get convoluted if both servers are XMail servers,
but let's just presume that the sending machine isn't, only the
destination.
Therefore it is up to th sending machine to decide to send a boucne on
first attempt or not, not to the receiving machine. Of course, if you
have this enabled for everybody (!) the actual mail client will also
cause this to happen, and give a reject message to the mail client.
That said, it is bad practice to do this to someone that has to use
this machine as an outgoing mail-server. (Dial-ups.) So it is advisable to
NOT use gray-listing when the user is authenticated. (Trusted user...
In theory... But let me not get into this topic...) I have a hunch
that this is where you might have shot yourself in the foot...
If the user is authenticated, the mail-client does not show a bounce,
as the server accepts the message based on the fact that the user has
authenticated, and bypasses glst. In order to test this then, a
message will have to be injected into an alternative server, which
then gets gray-listed by the XMail server...
So, in the filters.pre-data.tab file you should have:
"!aex" "/var/MailRoot/bin/glst" "--mfile" "@@FILE"
Which triggers the filter ONLY if the user has not authenticated.
And that should do it...
I find that gray-listing helps our server considerable, as it already
rejects about 99% of viruses coming from dial-ups. This however does
not mean that you can do away with the anti-virus-checking, as it's
the 1% that comes through, that is dangerous.
just for the sake of completeness, my glst.conf file looks as follows:
rejmsg=451 4.7.1 You have been greylisted. Please try again later. For
more details, see http://xxxxx/.
generr=0
rejerr=3
# 10 minutes
timeo=600
# 30 days...
exptimeo=2592000
# 2 hour
lametimeo=7200
# Exclude certain subnets from grey-listing...
xnet=127.0.0.1,255.255.255.255
xnet=196.x.x.0,255.255.255.0
xnet=196.x.x.0,255.255.255.0
xnet=196.x.x.x,255.255.255.255
xnet=196.x.x.0,255.255.255.0
mnet=0.0.0.0,0.0.0.0,255.255.255.0
The very last line treats every address as a class C (/24) instead of
individual hosts. I found this to be beneficial, as mails could
originate from various host on the same subnet. This is debatable,
but also a user preference thingy...
Also use the dbdump script to actually check what is inside the
database, to see if it worked...
You also have to make sure to clean up the DB every so often, i.e.:
0 2 * * * /var/MailRoot/bin/glst --cleanup --cfg /var/MailRoot/bin/glst.conf >>
/dev/null
The scary thing with glst, is watching sometimes up to 50 attempts in
about 10 minutes, whereby the spammer changes the from address
constantly, thereby generating a new triplet every time...
So, I hope this will give you the correct pointer as to what is
happening on your setup.
One problem I have with glst, is the non-existence of logging... This
is something I am working on, by Perl-wrapping the glst program. (I am
a log fanatic, and like to see lots of trails...) Doing this will also
make it possible to use ANY gray-listing program of choice.
Just as an aside, currently my server does:
Pre-Data (Non authenticated only)
gray-listing
spf-checks + some helo checks.
Post-Data
anti-virus (Clam)
spamassassin
I use the spf script as a plug to actually check hellos like IP
Number (x.x.x.x), negative numbers (ie -9287214126412), "localhost"
destination.domain etc. I also reject some domain as fail, even though
they are set as softfail, i.e. hotmail.com.
Cheers for now...
--
Best regards,
Jorn mailto:[EMAIL PROTECTED]
-
To unsubscribe from this list: send the line "unsubscribe xmail" in
the body of a message to [EMAIL PROTECTED]
For general help: send the line "help" in the body of a message to
[EMAIL PROTECTED]
