Re: [exim] *Suspect* Re: temporarily suspend mail delivery t…

Startseite
Nachricht löschen
Nachricht beantworten
Autor: W B Hacker
Datum:  
To: exim users
Alte Treads: Re: [exim] temporarily suspend mail delivery to an account
Betreff: Re: [exim] *Suspect* Re: temporarily suspend mail delivery to an account
Jason Keltz wrote:
> On 10/10/08 19:49, Jeroen van Aart wrote:
>> Jason Keltz wrote:
>>> I wonder if it's possible to add to my Exim configuration file, a 
>>> section that would temporarily suspend mail delivery to certain user 
>> If you have an alias file you could add an entry like:
>> name@???:    :defer:    texthere

>
> Hi Jeroen,
>
> Thanks for your response.
>
> The problem with this approach, I believe, is that the sender gets back
> "texthere", and the delivery is deferred. I would prefer for the
> message to be accepted by the system, but queued for delivery until the
> name is removed from the "temporary stop delivery" file.
>
> jas.
>
>
>


Think out of the box. No need for delays on queue. You have pleny of
other storage.

- craft a router that recognizes the 'temporary HOLD delivery' user-clan.

- have that router accept and make "A" delivery.

- but have the transport it calls make that delivery to a place in the
mailstore that is NOT where the user's POP /IMAP reaches.

EX:

Normal:

/var/mail/$domain/&local_part/<Maildir or mbox, or ...>

becomes:

/var/hold/$domain/$local_part/<Maildir or mbox, or ...>

- IOW a user-specific 'holding' dirtree. Standard structure (whatever
that is for your system), but not one from which they can pull messages.


- when the 'suspense' period is over, either move the messages into
their 'normal' mailstore (a scripted fs operation - Exim not involved)

CAVEAT: User wonders about the stale timestamps....

OR, (also with a script) pipe them back into Exim for ordinary delivery.

CAVEAT: user sees a current timestamp, but a delay en-route.


Even simpler:

In OUR case - *zero* alteration is needed to Exim routers or transports.

Reason? We store the per-domain and per-user mailstore type and path as
separate fields in an SQL DB, then 'build' a string defining the fs
dirtree in the router. Specifically the '/var/mail' or '/var/hold' part.

But one can do the same 'cheaper' with a CDB or flat-file.

All one needs to do is change one field in that DB, then perform the
'restoral' later.

HTH,

Bill Hacker