Hi All...

Ok, so there has been various comments around this. As you wish to
LIMIT delays on valid incoming, what you need to do is keep your
expire time-out on the database as long as possible.

My settings are as follows:

# 10 minutes
timeo=600
# 30 days...
exptimeo=2592000
# 2 hour
lametimeo=7200

This effectively means that if any e-mail does not re-enter the server
in 2 hours, the entry gets moved to the lameroos... This might be
overzealous, but works for this instance.

If it does re-enter, it will be kept in the database for 30 days,
Before expiring, effectively causing a re-check every 30 days on
regular mails. So if there is a stream of mail, that comes in
regularly, it will be immediate, but once a month it will be forced
through the grey-listing again.

This is the one you want to extend considerably should you want to
ensure minimum delays.

I am not sure if an incoming mail resets the date-stamp as it comes
in, back to the original 30 days, or wether the time-stamp just gets
left to the initial access. In which case it would mean that the
stream mail would never expire. Davide can possibly confirm/deny
that...

Even so, a 30 day re-prompt is valid enough for me...

As I run a cron doing the cleanup every two hours, a lamer entry could
become as old as 2 hours 59 minutes, which is not an issue to me...
Not much difference either or...

As to the secondary server, do the same. The chances are that an email
might hit both, which makes it a double delay. Some percentage
somewhere along the line... But, once it is in either of the two, that
server will accept it immediately. You then need to make sure that you
use an xnet on the primary for the secondary server, to make sure
there is not an added greylisting delay. Seeing as the secondary
should be trusted anyway, that is a good thing to do.

As a caveat on that, spammers tend to use the secondary MX only, in
the hope that it does not have a recipient list, and will blindly
accept for the domain, to pass it on, making it the problem of the
secondary server to deal with bounces...

As they get paid per e-mail sent, they don't care how it's sent, or if
it bounces after the fact that they have delivered it...

I have a few XNET entries in my file, including the xmalserver.org and
our fax sources, to prevent any unnecessary delays. So, if you have
sources that you know don't source spam, add an XNET to speed things
up...

-- 
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]

Reply via email to