OSEC

Neohapsis is currently accepting applications for employment. For more information, please visit our website www.neohapsis.com or email hr@neohapsis.com
 
Re: Adding HOLD_DEFER to access - Postfix access table format ?

From: Wietse Venema (wietseporcupine.org)
Date: Mon Feb 12 2007 - 13:36:45 CST

Victor Duchovni:
> On Mon, Feb 12, 2007 at 02:16:11PM -0500, Wietse Venema wrote:
>
> > Victor Duchovni:
> > > On Mon, Feb 12, 2007 at 01:45:09PM -0500, Wietse Venema wrote:
> > >
> > > > > I am thinking to make a version of greylisting where mails
> > > > > are put in HOLD queue and server reply with defer
> > > > > (using smtpd_end_of_data_restrictions + check_policy_service)
> > > > > This way I could fast deliver some msg if needed. But for this
> > > > > a new action needs to be added to access table , maybe HOLD_DEFER
> > > > > and HOLD_REJECT ?
> > > >
> > > > HOLD stores the message in the queue.
> > > >
> > > > DEFER tells the client to try deliver the message another time.
> > > >
> > > > The combination makes no sense at all.
> > >
> > > Well, it does if one wants to compute a checksum of the held message,
> > > and apply some expensive analytics, wait for signature updates, ...
> > > and to to allow delivery only when the client comes back with the same
> > > message a second (later) time. If the client never comes back, no
> > > message is delivered.
> >
> > One does not need HOLD (and the queue abuse) for that. A simple
> > lookup table with header/body hashes is sufficient. It also uses
> > less space.
>
> Yes, as soon as the expensive (possibly somewhat delayed for signature
> updates, ...) processing is done, one can discard the message and store
> just the hash.

And this hashing will have to happen before the SMTP session ends,
otherwise a backlog of to-be-hashed content builds up, and that
would render the whole idea unusuable.

> I agree that this is not a job for HOLD+DEFER, the concept of deferring
> and keeping a copy is fine, but the Postfix access(5) (and policy)
> machinery is not the right vehicle.

I agree that this is not a job for HOLD+DEFER, because it would be
a mistake to queue to-be-hashed mail for any amount of time.

        Wietse