Re: Outgoing queue....

[Matti Aarnio <mea@nic.funet.fi>]

On Fri, Feb 09, 2001 at 07:46:42PM +0100, Arnt Gulbrandsen wrote:
> "David L. Potter" <potter@chebucto.ns.ca>
> > Thanks for pointing this out... I must admit I'd forgotten about some of 
> > these utilities.
> > 
> > While I'm not familiar with the term 'quinche' it appears from the context 
> > that it means 'quiet'.
> 
> I suspect the author meant to write quench, but should have written kill.

  The  'utils/expirer.sh' is very old first-order approximation on the issue,
  use  manual-expirer  instead, far better.

> > I would assume that means that along with the 
> > scheduler, all transport agents and router processes must also be 
> > stopped? Am I right in assuming that smtpserver processes could possibly
> > continue...?
> 
> Stop the scheduler. You can let the routers and smtpservers go on.
> 
> If you run it while the scheduler is running, nothing terribly bad's going
> to happen, I suspect. Matti?

  I use  'manual-expirer' regularly to blow away hundreds of messages destined
  to varying locations.   Works like charm.  (But see TODO, there is room
  for improvement... it is really the Scheduler which should do the killing
  of message/recipient/channel/whatnot. By using 'expirer' perhaps, but still.)

> > And while this looks like it will work, with the increasing amount of 
> > spam we face, I was hoping for a method that could be used 'on the fly' 
> > and would cover a longer time period.
> > 
> > At one point I though about an `expirer ` type program that would search 
> > messages down and simply (mv) remove them from the queue... however
> 
> That's effectively what that program does... except that it does it the
> right way, by writing the "I'm done with this recipient" byte in the file.

  Right, so that when a message has MULTIPLE recipients (domains), you won't
  blow them all way, only that which you really want to kill.

> > Neither  `expirer ` or my idea work as well as I would like because, in 
> > part, I'm seeing spam being relayed off of several sites (which makes it 
> > difficult to block) but then end up with a common 'channel/host', stuck 
> > for several days in the outbound queue and with new arrivals appearing 
> > (possibly from new relay sites) over several days... yuck!
> 
> Yeah... anything that tries to deal with spam seems to be yucky :(

  Perhaps running smtpserver with recipient address verification
  synchronously with injection -- at least nonexistent local destinations
  won't get accepted and then futilely rejected.

  smtpserver.conf:  PARAM  enable-router
		    * 999 ftveR

  zmailer.conf:     ROUTEUSER_IN_ABNORMAL_UNIX=

  Those two file tweaks, and restarting the router  (recent scripts),
  and RCPT TO:<bxzncbzxncb@localhost>  will get bounced with "no such user".

  Example run at  nic.funet.fi:

mail from:<>
250 Ok (sourcechannel 'error' accepted) Ok
rcpt to:<jshfjsdh@nic.funet.fi>
554 unresolvable address: <jshfjsdh@nic.funet.fi> Failed

  Of course this is a trade-off in between heavyness of router start for
  each incoming SMTP session, and then throwing away its results, vs.
  accepting junk email to nonexistent locals, which can't be returned.

> --Arnt

-- 
/Matti Aarnio	<mea@nic.funet.fi>