Mailing List Archive

Perl integration - context?
Hello,

Is it possible with Exim’s Perl integration to create a reference that will last throughout a message’s delivery and then be reaped?

I’d like to explore an flock-based lock for mail delivery that would allow an external process to suspend delivery by holding a lock on a designated path: if Exim/Perl does flock($fh, LOCK_SH) and fails EAGAIN, then Exim will defer acceptance of the message.

When the flock() succeeds, ideally that flock()ed Perl $fh will last until delivery is done and then be reaped. Is it safe to store that in a Perl global, then call something else at the end of the routing that deletes/undefs that global? Or is there some cleaner way to give Exim such a reference and have Exim hold onto it for me until routing/delivery is over?

Thank you!

cheers,
-Felipe Gasper
--
## List details at https://lists.exim.org/mailman/listinfo/exim-users
## Exim details at http://www.exim.org/
## Please use the Wiki with this list - http://wiki.exim.org/
Re: Perl integration - context? [ In reply to ]
On Wed, 9 Jun 2021, Felipe Gasper via Exim-users wrote:

> Hello,
>
> Is it possible with Exim???s Perl integration to create a reference
> that will last throughout a message???s delivery and then be reaped?
>
> I???d like to explore an flock-based lock for mail delivery that
> would allow an external process to suspend delivery by holding a
> lock on a designated path: if Exim/Perl does flock($fh, LOCK_SH)
> and fails EAGAIN, then Exim will defer acceptance of the message.
>
> When the flock() succeeds, ideally that flock()ed Perl $fh will
> last until delivery is done and then be reaped. Is it safe to
> store that in a Perl global, then call something else at the end
> of the routing that deletes/undefs that global? Or is there some
> cleaner way to give Exim such a reference and have Exim hold onto
> it for me until routing/delivery is over?

I am reminded of the exim_lock utility, though that is an external process.

I'm a bit confused.
Are you trying to stop a second message from being accepted *into the
exim queue* whilst the first is being routed/delivered ?

A message is often accepted and delivered by separate exim processes
(it may sit in the queue until some remote event happens)
so I'm not sure that exim can hold a lock through the whole delivery.

Another way the delivery flow is modified is to move a message
between two queues ...

--
Andrew C. Aitchison Kendal, UK
andrew@aitchison.me.uk
--
## List details at https://lists.exim.org/mailman/listinfo/exim-users
## Exim details at http://www.exim.org/
## Please use the Wiki with this list - http://wiki.exim.org/
Re: Perl integration - context? [ In reply to ]
> On Jun 9, 2021, at 3:00 PM, Andrew C Aitchison <andrew@aitchison.me.uk> wrote:
>
> On Wed, 9 Jun 2021, Felipe Gasper via Exim-users wrote:
>
>> Hello,
>>
>> Is it possible with Eximâ??s Perl integration to create a reference
>> that will last throughout a messageâ??s delivery and then be reaped?
>>
>> Iâ??d like to explore an flock-based lock for mail delivery that
>> would allow an external process to suspend delivery by holding a
>> lock on a designated path: if Exim/Perl does flock($fh, LOCK_SH)
>> and fails EAGAIN, then Exim will defer acceptance of the message.
>>
>> When the flock() succeeds, ideally that flock()ed Perl $fh will
>> last until delivery is done and then be reaped. Is it safe to
>> store that in a Perl global, then call something else at the end
>> of the routing that deletes/undefs that global? Or is there some
>> cleaner way to give Exim such a reference and have Exim hold onto
>> it for me until routing/delivery is over?
>
> I am reminded of the exim_lock utility, though that is an external process.
>
> I'm a bit confused.
> Are you trying to stop a second message from being accepted *into the
> exim queue* whilst the first is being routed/delivered ?

The idea is more to prevent message delivery during a backup or account reconfiguration.

I specifically want to avoid this:

1. External process suspends user’s mail delivery.
2. External process gets SIGKILL.
3. User gets no more mail until user complains ($$) and someone manually ($$) reenables the user’s mail.

Using flock() for this would cause the mail suspension to go away automatically once whatever holds that lock goes away:

1. External process flock(EX)s user’s special designated file.
2. Exim tries to flock(SH) that same file, gets EAGAIN.
3. Exim tells clients :defer:
4. External process finishes or gets SIGKILL.
5. User can receive mail again, no manual intervention needed.

Alternatively:

1. Exim flock(SH)s the user’s special file.
2. External process tries to flock(EX), gets EAGAIN. Either retries later or just fails.

-FG
--
## List details at https://lists.exim.org/mailman/listinfo/exim-users
## Exim details at http://www.exim.org/
## Please use the Wiki with this list - http://wiki.exim.org/
Re: Perl integration - context? [ In reply to ]
On Wed, 9 Jun 2021, Felipe Gasper via Exim-users wrote:

> The idea is more to prevent message delivery during a backup or account reconfiguration.

exim_lock is the tool you are looking for.

--
Andrew C. Aitchison Kendal, UK
andrew@aitchison.me.uk

--
## List details at https://lists.exim.org/mailman/listinfo/exim-users
## Exim details at http://www.exim.org/
## Please use the Wiki with this list - http://wiki.exim.org/
Re: Perl integration - context? [ In reply to ]
On 09/06/2021 18:37, Felipe Gasper via Exim-users wrote:
> Is it possible with Exim’s Perl integration to create a reference that will last throughout a message’s delivery and then be reaped?
>
> I’d like to explore an flock-based lock for mail delivery that would allow an external process to suspend delivery by holding a lock on a designated path: if Exim/Perl does flock($fh, LOCK_SH) and fails EAGAIN, then Exim will defer acceptance of the message.

I think you're being over-complicated.

You only seem to need some form of expansion that you can run from an ACL
which results in a defer. The expansion could be perl, could be file-existence,
could be a DB lookup. There's no need to delce into locking.
--
Cheers,
Jeremy

--
## List details at https://lists.exim.org/mailman/listinfo/exim-users
## Exim details at http://www.exim.org/
## Please use the Wiki with this list - http://wiki.exim.org/
Re: Perl integration - context? [ In reply to ]
> On Jun 10, 2021, at 12:39 AM, Andrew C Aitchison via Exim-users <exim-users@exim.org> wrote:
>
> On Wed, 9 Jun 2021, Felipe Gasper via Exim-users wrote:
>
>> The idea is more to prevent message delivery during a backup or account reconfiguration.
>
> exim_lock is the tool you are looking for.

Ah ok. I knew this tool existed but hadn’t realized it auto-unlocks.

Thank you!

-FG
--
## List details at https://lists.exim.org/mailman/listinfo/exim-users
## Exim details at http://www.exim.org/
## Please use the Wiki with this list - http://wiki.exim.org/
Re: Perl integration - context? [ In reply to ]
> On Jun 10, 2021, at 00:52, Andrew C Aitchison <andrew@aitchison.me.uk> wrote:
>
> ?
>> On Wed, 9 Jun 2021, Felipe Gasper via Exim-users wrote:
>>
>> The idea is more to prevent message delivery during a backup or account reconfiguration.
>
> exim_lock is the tool you are looking for.

With this tool is there any way to differentiate “waiting for lock” from “lock acquired” other than parsing the output stream?

-F

--
## List details at https://lists.exim.org/mailman/listinfo/exim-users
## Exim details at http://www.exim.org/
## Please use the Wiki with this list - http://wiki.exim.org/
Re: Perl integration - context? [ In reply to ]
On Thu, 10 Jun 2021, Felipe Gasper via Exim-users wrote:

>> On Jun 10, 2021, at 00:52, Andrew C Aitchison <andrew@aitchison.me.uk> wrote:
>>
>>> On Wed, 9 Jun 2021, Felipe Gasper via Exim-users wrote:
>>>
>>> The idea is more to prevent message delivery during a backup or account reconfiguration.
>>
>> exim_lock is the tool you are looking for.
>
> With this tool is there any way to differentiate
> "waiting for lock"from "lock acquired"
> other than parsing the output stream?

From spec.txt 54.15 Mailbox maintenance (exim_lock)
The utility requires the name of the file as its first argument.
If the locking is successful, the second argument is run as a command
(using C's system() function); if there is no second argument, the
value of the SHELL environment variable is used; if this is unset or
empty, /bin/sh is run. When the command finishes, the mailbox is
unlocked and the utility ends.

Your backup/account maintenance script doesn't need to know anything
about the lock; exim_lock only runs your command or script once it has
acquired a lock. Neither spec.txt nor the Debian/Ubuntu man page say
anything about return codes so you would have to investigate further
to see how to check whether your job succeeded.

--
Andrew C. Aitchison Kendal, UK
andrew@aitchison.me.uk

--
## List details at https://lists.exim.org/mailman/listinfo/exim-users
## Exim details at http://www.exim.org/
## Please use the Wiki with this list - http://wiki.exim.org/