Mandi! Leonardo Boselli via Exim-users
In chel di` si favelave...
> What is easier way ?
Not 'easier', but... consider also some 'offline' transport system, like
UUCP.
On online host you queue email to UUCP, and intermittent host simply fetch
them when needed.
--
Il Re di Spagna fece
On 1/19/22 08:57, Jasen Betts via Exim-users wrote:
exim can be configured how long to retry for and when to warn,
you can set it to 6 months if you want (well, you might have to say
183 days I don't think exim understands months)
Maximum seems to bee weeks:
s seconds
m minutes
h
On 2022-01-18, Leonardo Boselli via Exim-users wrote:
> On Tue, 18 Jan 2022, Odhiambo Washington wrote:
>> I still believe that it's better to solve the problem from the source -
>> where the connectivity is almost unpredictable.
>
> log time unconnections are predictable, since does not occour
On 18/01/2022 15:24, Odhiambo Washington via Exim-users wrote:
he OP would rather mess up with the retry
times
To be fair, that's the quickest way to ensure that Exim doesn't
freeze or bounce a message waiting in spool, which is needed
whatever the eventual delivery method is.
--
Cheers,
On Tue, Jan 18, 2022 at 3:58 PM Cyborg via Exim-users
wrote:
> Am 18.01.22 um 12:02 schrieb Odhiambo Washington via Exim-users:
> > Hi Leonardo,
> >
> > If I were you, I'd approach the problem a different way. I remember doing
> > something like that with intermittently connected hosts.
> > I
Am 18.01.22 um 12:02 schrieb Odhiambo Washington via Exim-users:
Hi Leonardo,
If I were you, I'd approach the problem a different way. I remember doing
something like that with intermittently connected hosts.
I would instead just queue the messages and let p.example.com to request
for their
On Tue, 18 Jan 2022, Odhiambo Washington wrote:
I still believe that it's better to solve the problem from the source -
where the connectivity is almost unpredictable.
log time unconnections are predictable, since does not occour by a
failure, but intentionally, and system manager for both
On Tue, Jan 18, 2022 at 3:10 PM Leonardo Boselli via Exim-users <
exim-users@exim.org> wrote:
> On Tue, 18 Jan 2022, Odhiambo Washington via Exim-users wrote:
> > If I were you, I'd approach the problem a different way. I remember doing
> > something like that with intermittently connected hosts.
On 18 Jan 2022, at 11:56, Leonardo Boselli via Exim-users
wrote:
> No, my situation is different: the p machine normally is connected, but for
> some reason, can be unconnected for extended (days to weeks) periods of time,
> or ever, more likely, to have the smtp service unactive, or even just
On Tue, 18 Jan 2022, Odhiambo Washington via Exim-users wrote:
If I were you, I'd approach the problem a different way. I remember doing
something like that with intermittently connected hosts.
I would instead just queue the messages and let p.example.com to request
for their delivery when its
On Tue, Jan 18, 2022 at 1:59 AM Leonardo Boselli via Exim-users <
exim-users@exim.org> wrote:
> I have two hosts a.example.com and p.example.com .
> mail for example com arrive to A, but for some users is forwarded to
> u...@p.example.com .
> Nothing special until here, you do with a procmail
On Mon, 17 Jan 2022, Leonardo Boselli via Exim-users wrote:
I have two hosts a.example.com and p.example.com .
mail for example com arrive to A, but for some users is forwarded to
u...@p.example.com .
Nothing special until here, you do with a procmail option at user level.
The problem is that
On 17/01/2022 22:56, Leonardo Boselli via Exim-users wrote:
What i want to do is that when sending a message to p.example.com whatever
thing happens (no route to host/ dns error / no response / closed port / 4xx or
5xx error), anything different than an accepted message, the message remains in
I have two hosts a.example.com and p.example.com .
mail for example com arrive to A, but for some users is forwarded to
u...@p.example.com .
Nothing special until here, you do with a procmail option at user level.
The problem is that host p could be disconnected, sometime also for
weeks, or
14 matches
Mail list logo
