[Greylist-users] Time to resend a message

[Ken Raeburn]

On Jul 5, 2005, at 04:41, Matthias Haeker wrote:
> there is a ongoing discussion on how to understand the resending time 
> frame=
>
> in that a message shoud be resend after beeing rejectet with a lets 
> say:
>
> 450: ...........( Greylistet for 300 sec)
>
>
> must i resend **within** the 300sec or earlyest after the 300sec.

The basic idea of greylisting is that the sending site should queue up 
messages on a temporary error (the 450 error code), and retry 
periodically for some amount of time, where the delay between tries and 
the amount of time before the sender finally gives up should be 
"reasonable".  What "reasonable" means varies, of course, but usually a 
site will retry anywhere from every 15 minutes to once every few hours, 
and will keep trying for at least 3-4 days, maybe a week.

However, for legitimate mail, this does introduce a delay.  (There's a 
lot more to it, where typically you keep track of who's tried to send 
mail from what addresses before, and if the sending mailer does retry 
the mail, then in the future, at least for a while, you accept the mail 
without delay.)

Greylisting tends to win, because most spamming software doesn't retry 
at all, and if it does, it usually retries immediately, several times, 
and then gives up.  So retry attempts within the first very short 
period of time are still given the temporary failure code; this is 
probably what the "300 sec" refers to -- your mailer should make 
another attempt after 5 minutes, and the mail should get through.  But 
if you're using a typical mailer configuration, you probably are using 
"reasonable" values, and the mail should eventually go through.  Resend 
attempts within the 5 minute window shouldn't be a problem, though; 
they'll just get more temporary failure indications and stay in your 
mail queue.


> please excouse if ther is already a thread in your mailing list 
> regarding t=
> his question.
>
> i am not a greylist user, the companys i am the admin from dont send 
> any sp=
> am and i have not the time to leran everything
> about all new "ANTISPAM" solutions.
>
> but we are realy troubled to send valid genuine email to customer 
> using gre=
> ylisting.

You don't say whether the mail is actually getting through, in the end. 
  But if your site and the site using greylisting are configured 
reasonably normally, it should be nothing worse than delaying the 
initial messages between parties (specifically, SMTP envelope 
addresses) at your two sites who haven't talked before (at least, 
recently).

There are some mail handling techniques that can cause problems when a 
site is using greylisting, though:

  * VERP -- variable envelope return path addresses, often but not 
always in mailing lists, where the SMTP sender has a form that may look 
something like "<ListName>-<MessageNumber>-<Recipient>@hostingsite.com" 
and is different for every message.
  * sending server pools -- If one sending attempt comes from one IP 
address, and the next attempt comes from a different IP address, the 
typical greylisting implementation will not see them as related, and 
would treat both of them as first contacts from different potential 
spammer sites, returning temporary failures and waiting to see if 
either attempts to resend (from the same address).  Usually, there's a 
timeout on how long a site can wait before resending before the 
greylist implementation throws away the data -- if you don't retry 
within some "reasonable" time, it assumes you probably were a spammer 
and gave up, so it forgets about you.  Because of this, if you've got a 
large sending pool, and/or don't retry very often, the greylist 
database record for one of your sending servers might be discarded 
before that server gets around to trying to send the message again.

In the worst case, you can try to contact the postmaster at the site 
you're having trouble with, and see if either they're doing something 
wrong, or they think you're doing something wrong, or whatever else 
might be amiss, and you can work together to fix it.  (You might also 
suggest to them that in the SMTP message they send back, since it looks 
like they're trying to make it informative, they could include a URL 
for a web page explaining things a little better.)

I hope this helps....

Ken