[Greylist-users] Handling servers that don't wait on their retries

Dennis Wynne DWynne at equinoxis.com
Thu Feb 26 09:01:42 PST 2009


I have connection and rate limits set in any case, and that would
certainly slow them down if they keep retrying without much pause.

IIRC, these are not reset until the offending server quits trying to
connect. So if some server connects too much then we start blocking it
and we keep it blocked (denying connection per these settings) until the
quit trying. So "in theory" a poorly set up server might take forever to
deliver the mail since they would keep banging on our server but we
don't answer until after time passes after their last attempt.

*I* changed the settings to keep these machine gunner spammers from
beating on the server, and not to keep legit mail out (or further delay
it).  I have not seen a problem like Ian describes, I don't think, but I
would think my server could handle it.

Dennis




> -----Original Message-----
> From: greylist-users-bounces at lists.puremagic.com 
> [mailto:greylist-users-bounces at lists.puremagic.com] On Behalf 
> Of Stephen Carr
> Sent: Wednesday, February 25, 2009 11:30 PM
> To: Greylisting Users and Developers Discussion
> Subject: Re: [Greylist-users] Handling servers that don't 
> wait on their retries
> 
> Dear Ian
> 
> I think I solved this problem by setting the ClientConn and 
> ClientRate in access file
> 
> I see instances of hundreds of connections from a site in a 
> few minutes but they are rejected eg
> 
> sendmail [13785]: ruleset=check_relay, arg1=[201.15.201.113], 
> arg2=201.15.201.113, relay=[201.15.201.113], reject=421 4.3.2 
> Connection rate limit exceeded.
> 
> before the are handled by relaydelay.
> 
> Regards
> Stephen Carr
> 
> 
> Ian Ballantyne wrote:
> > Hi,
> >
> > Before I even get started here with my second attempt to post this, 
> > I've made a slight mess tonight, sending mails to the wrong address 
> > (requests instead of users), messing up my config so that mails get 
> > rejected that shouldn't have been, and sending other 
> strange mails as 
> > a result.  To those at the receiving end of my mistakes tonight, 
> > sorry.....
> >
> > On to the post as it was originally intended:
> >
> > This problem has been around for a while for me, and I have had a 
> > solution in place now also for a long time now which I 
> would like to 
> > share, and which I hope will get included in the relaydelay script.
> >
> > There are some mail servers that connect to mine and get greylisted 
> > for a while.
> > These however do not wait with their retries, instead retrying 
> > repeatedly until the block expires.  These retries are 
> usually spaced 
> > only a few seconds apart, resulting in hundreds of retries 
> during the 
> > block period and an unnecessary server and network load.  I have 
> > complained to the server admins, pointing out RFC 2821 section 
> > 4.5.4.1, however they do not change their configurations instead 
> > telling me their servers are fine.
> >
> > I modified the relaydelay script and added functionality 
> that rejects 
> > emails if the sending server refuses to behave correctly 
> and not retry 
> > too often during the block period.  It is simply checks the 
> > blocked_count and if it gets over a threshhold, then it rejects the 
> > mail with a 554, 5.7.0 error.  As far as I can tell, this 
> is the most 
> > appropriate error respons code in this situation.
> > I have
> > not programmed in anything to undo the block, it gets automatically 
> > removed when the record expires and is moved to the reporting table 
> > after 36 days.
> >
> > I have included two patches below, one for the conf file 
> and one for 
> > the perl script.  Don't kill me for my coding, I'm no perl 
> programmer, 
> > so I hope what I've written is ok.
> >
> > I would appreciate some feedback on this.  My hope is that if this 
> > gets spread widely enough, admins of misbehaving mail servers will 
> > correct their configs.
> > What do the people on this list think of this?
> >
> > And finally, I hope you can understand what I'm on about.  
> I'm rather 
> > tired, which usually means I can't express myself that well...... 
> > (addenum: and make some really stupid mistakes...)
> >
> > regards from Vienna, Austria
> > Ian
> >
> >
> >
> >
> > --- relaydelay.0.04.conf        2009-02-25 22:30:25.000000000 +0100
> > +++ relaydelay.0.05.conf        2009-02-25 22:21:22.000000000 +0100
> > @@ -155,6 +155,11 @@
> >  #   used if $reverse_mail_tracking is enabled.
> >  $reverse_mail_life_secs = 4 * 24 * 3600;  # 4 Days
> >
> > +# This sets the maximum number of retires we are willing 
> to tolerate
> > +#   before deciding that a mail server does not 
> sufficiently observe
> > +#   RFC 2821 section 4.5.4.1. Anything over this will get rejected.
> > +$max_retry_attempts = 10;
> > +
> >  #############################################################
> >  # End of options for use in external config file  
> > #############################################################
> >
> >
> > -------------------------------------------------------
> >
> >
> > --- relaydelay.0.04.pl  2009-02-25 22:22:13.000000000 +0100
> > +++ relaydelay.0.05.pl 2009-02-25 22:24:41.000000000 +0100
> > @@ -186,6 +186,11 @@
> >  #   used if $reverse_mail_tracking is enabled.
> >  my $reverse_mail_life_secs = 4 * 24 * 3600;  # 4 Days
> >
> > +# This sets the maximum number of retires we are willing 
> to tolerate
> > +#   before deciding that a mail server does not 
> sufficiently observe
> > +#   RFC 2821 section 4.5.4.1. Anything over this will get rejected.
> > +my $max_retry_attempts = 10;
> > +
> >
> >  #############################################################
> >  # End of options for use in external config file @@ -735,7 
> +740,7 @@
> >    }
> >
> >    # Check to see if we already know this triplet set, and if the 
> > initial block is expired
> > -  my $query = "SELECT id, NOW() > block_expires, origin_type, 
> > relay_ip FROM relaytofrom "
> > +  my $query = "SELECT id, NOW() > block_expires, origin_type, 
> > + relay_ip,
> > blocked_count FROM relaytofrom "
> >      .         "  WHERE record_expires > NOW() "
> >      .         "    AND mail_from = " . $dbh->quote($mail_from)
> >      .         "    AND rcpt_to   = " . $dbh->quote($rcpt_to);
> > @@ -757,12 +762,18 @@
> >
> >    my $sth = $dbh->prepare($query) or goto DB_FAILURE;
> >    $sth->execute() or goto DB_FAILURE;
> > -  ($rowid, my $block_expired, my $origin_type, my 
> $recorded_relay_ip) 
> > = $sth->fetchrow_array();
> > +  ($rowid, my $block_expired, my $origin_type, my 
> $recorded_relay_ip, 
> > + my
> > $blocked_count) = $sth->fetchrow_array();
> >    goto DB_FAILURE if ($sth->err);
> >    $sth->finish();
> >
> >    if (defined $rowid) {
> > -    if ($block_expired) {
> > +    if ($blocked_count > $max_retry_attempts) {
> > +      # Too many retries, the mail server sending the mail doesn't
> > observe RFC 2821, section 4.5.4.1
> > +      #    Reject the mail.
> > +      print "  Email is known but too many retires to deliver
> > $blocked_count  Rejecting with 550.\n" if ($verbose);
> > +      goto BOUNCE_MAIL;
> > +    }
> > +    elsif ($block_expired) {
> >        print "  Email is known and block has expired.  
> Passing the mail.
> > rowid: $rowid\n" if ($verbose);
> >        # If this record is a reverse tracking record with 
> unknown IP, then
> >        #   update it to include the now-known IP (if 
> tracking is enabled)
> > @@ -857,10 +868,12 @@
> >
> >
> >    BOUNCE_MAIL:
> > -  # We don't use this anywhere yet, but may in future...
> > -  # set privdata so later callbacks won't have problems
> > -  $privdata = "0";
> > -  $ctx->setpriv(\$privdata);
> > +  if (defined $rowid) {
> > +    $dbh->do("UPDATE relaytofrom SET blocked_count = 
> blocked_count + 
> > + 1
> > WHERE id = $rowid") or goto DB_FAILURE;
> > +    $privdata = "$rowids\x00$mail_from\x00$rcpt_to";
> > +  }
> > +  $ctx->setpriv($privdata_ref);
> > +  $ctx->setreply("554", "5.7.0", "Rejected by Greylisting, too many
> > delivery retries. See RFC 2821 section 4.5.4.1 and contact 
> your mail 
> > server administrator.");
> >    # Indicate the message should be aborted (want a custom 
> error code?)
> >    return SMFIS_REJECT;
> >
> >
> > -------------------------------------------------------
> > _______________________________________________
> > Greylist-users mailing list
> > Greylist-users at lists.puremagic.com
> > http://lists.puremagic.com/cgi-bin/mailman/listinfo/greylist-users
> >
> >
> 
> 
> --
> Stephen Carr
> Computing Officer
> School of Civil and Environmental Engineering The University 
> of Adelaide Tel +618-8303-4313 Fax +618-8303-4359 Email 
> sgcarr at civeng.adelaide.edu.au
> 
> CRICOS Provider Number 00123M
> -----------------------------------------------------------
> This email message is intended only for the addressee(s)and 
> contains information that may be confidential and/or 
> copyright.  If you are not the intended recipient please 
> notify the sender by reply email and immediately delete this 
> email. Use, disclosure or reproduction of this email by 
> anyone other than the intended recipient(s) is strictly 
> prohibited. No representation is made that this email or any 
> attachments are free of viruses. Virus scanning is 
> recommended and is the responsibility of the recipient.
> 
> _______________________________________________
> Greylist-users mailing list
> Greylist-users at lists.puremagic.com
> http://lists.puremagic.com/cgi-bin/mailman/listinfo/greylist-users
> 


More information about the Greylist-users mailing list