Milter-greylist

Hi,

Some legitimate emails get greylisted for 90 hours and more, and I'm trying to
understand why.

What cases would cause such very very long greylisting?

I frequently (a few times a day) also see greylisting of emails for 7 hrs and
a little more, and looking at logs I can't understand why.

So I'm also wondering, what analysis / trouble-shooting should I be performing
to determine why such lengthy delays occur? and what can I do to "fix" such
issues other than whitelisting the sending domain.

Thanks.

Michael.

Michael Mansour <mic@...> wrote:

> Some legitimate emails get greylisted for 90 hours and more, and I'm trying to
> understand why.

The sender does not retry before that time, or it uses a mail pool: it
tried from different IP before trying again with the first one.

-- 
Emmanuel Dreyfus
http://hcpnet.free.fr/pubz
manu@...

Michael Mansour wrote:
> Hi,
> 
> Some legitimate emails get greylisted for 90 hours and more, and I'm trying to
> understand why.
> 
> What cases would cause such very very long greylisting?
> 
> I frequently (a few times a day) also see greylisting of emails for 7 hrs and
> a little more, and looking at logs I can't understand why.
> 
> So I'm also wondering, what analysis / trouble-shooting should I be performing
> to determine why such lengthy delays occur? and what can I do to "fix" such
> issues other than whitelisting the sending domain.

  Since you have no control over the retry time used by the sender,
your only option to speed up the delivery is to whitelist at your
side of the connection.  This is especially true for those broken
mail servers that don't retry at all.

On 10/4/07, Brian W. Antoine <briana@...> wrote:
>  This is especially true for those broken
>  mail servers that don't retry at all.

...or the ones that try each mx once and then quits which is not good
if you don't use mx sync (or it doesn't work). There's also mail
servers that try plenty of times but with no reasonable interval
between, like 10 times in less than a minute and then quit.

Is there such a thing as a properly configured mail server? :-) Even
though I try to convince my customers that it's the connecting server
that is at fault I always end up with adding yet another whitelist
entry.

-- 
/peter

shuttlebox wrote:
> On 10/4/07, Brian W. Antoine <briana@...> wrote:
>>  This is especially true for those broken
>>  mail servers that don't retry at all.
> 
> ...or the ones that try each mx once and then quits which is not good
> if you don't use mx sync (or it doesn't work). There's also mail
> servers that try plenty of times but with no reasonable interval
> between, like 10 times in less than a minute and then quit.
> 
> Is there such a thing as a properly configured mail server? :-) Even
> though I try to convince my customers that it's the connecting server
> that is at fault I always end up with adding yet another whitelist
> entry.

  There are plenty of properly configured servers out there, though
the number decreases as the size of the company they serve increases. :)

  The ISP I worked at had a different solution to broken mail servers,
we allowed the user to disable greylisting on their account via a checkbox
on a mail service config webpage.  The webpage explained exactly what was
happening and what would happen if they disabled greylisting, since we
also sent out daily reports about what had been greylisted from their
account during the previous 24 hours.

  I found that over half the people who turned it off, immediately turned
it back on, having decided they didn't need the email from that server
as bad as they thought they did.  These were for accounts that had existed
for years and were widely harvested and spammed.  For newer accounts, it
tended to get turned off and left off, until they'd used the account for
a few months and the email address started getting spammed, then they'd
turn it back on.