Re: Best practice - concurrent delivery to remote sites

2018-12-06 Thread Andrey Repin
Greetings, Viktor Dukhovni! >> On Dec 6, 2018, at 2:19 PM, Andrey Repin wrote: >> >> In other words, if I have multiple different messages to the same >> destination, >> I can't know if they will be delivered through single connection? >> And can't control it? > If the inter-message spacing

Re: Best practice - concurrent delivery to remote sites

2018-12-06 Thread Viktor Dukhovni
> On Dec 6, 2018, at 2:19 PM, Andrey Repin wrote: > > In other words, if I have multiple different messages to the same destination, > I can't know if they will be delivered through single connection? > And can't control it? If the inter-message spacing exceeds the either of:

Re: Best practice - concurrent delivery to remote sites

2018-12-06 Thread Andrey Repin
Greetings, Viktor Dukhovni! >>> The default amount of delay that is inserted between individual deliveries >>> over the same message delivery transport, regardless of destination. If >>> non-zero, all deliveries over the same message delivery transport will >>> happen one at a time. >> >> To me,

Re: Best practice - concurrent delivery to remote sites

2018-12-06 Thread Viktor Dukhovni
> On Dec 6, 2018, at 1:28 PM, Andrey Repin wrote: > >> The default amount of delay that is inserted between individual deliveries >> over the same message delivery transport, regardless of destination. If >> non-zero, all deliveries over the same message delivery transport will >> happen one at

Re: Best practice - concurrent delivery to remote sites

2018-12-06 Thread Andrey Repin
Greetings, Wietse Venema! >> default_transport_rate_delay = 15s I'd like to ask for clarification, as man page wording is not clear. The original wording is > The default amount of delay that is inserted between individual deliveries > over the same message delivery transport, regardless of

Re: Best practice - concurrent delivery to remote sites

2018-12-06 Thread Andrey Repin
Greetings, Wietse Venema! > Wietse: >> > I don't think that there is a 'standard' policy that 'works' for >> > delivery from every site to every site. >> > >> > Nowadays you get a policy exception from 'big' receivers, and you >> > come up with transport_maps with different 'classes' of delivery

Re: Best practice - concurrent delivery to remote sites

2018-12-06 Thread Wietse Venema
Wietse: > > I don't think that there is a 'standard' policy that 'works' for > > delivery from every site to every site. > > > > Nowadays you get a policy exception from 'big' receivers, and you > > come up with transport_maps with different 'classes' of delivery > > agents that are configured

Re: Best practice - concurrent delivery to remote sites

2018-12-06 Thread Stefan Bauer
Thank you Wietse, wouldn't default_transport_rate_delay = 15s be a safe setting to relax the whole transport a bit? from a receivers perspective, that's something i would like to see instead of having ongoing delivery. Am Do., 6. Dez. 2018 um 14:41 Uhr schrieb Wietse Venema <

Re: Best practice - concurrent delivery to remote sites

2018-12-06 Thread Wietse Venema
Stefan Bauer: > stuff/best practice that makes the process more effective. > > i'm certain that remote sites prefer one way over the other. I don't think that there is a 'standard' policy that 'works' for delivery from every site to every site. Nowadays you get a policy exception from 'big'

Re: Best practice - concurrent delivery to remote sites

2018-12-06 Thread Andrey Repin
Greetings, Stefan Bauer! > ack. but i was looking for advices like e.g: > initially defer mail delivery for lets say a minute to be able to send out > a bunch of mails to same recipient in a single session instead of having 100 > independant sessions. For queue management, look at

Re: Best practice - concurrent delivery to remote sites

2018-12-06 Thread Stefan Bauer
ack. but i was looking for advices like e.g: initially defer mail delivery for lets say a minute to be able to send out a bunch of mails to same recipient in a single session instead of having 100 independant sessions. stuff/best practice that makes the process more effective. i'm certain that

Re: Best practice - concurrent delivery to remote sites

2018-12-06 Thread Andrey Repin
Greetings, Stefan Bauer! >>> we're running a small relay-service and looking for best practice to >>> deliver mails to remote sites regarding concurrent delivery and so on. >> >> >>> Sometimes, we have customers that are sending several mails per second to >>> same recipients. >> >>

Re: Best practice - concurrent delivery to remote sites

2018-12-06 Thread Stefan Bauer
Its no user issue. Its a real and legal use case that customers send several mails / second to same recipient over a long period (software tests whatever). Am Do., 6. Dez. 2018 um 12:50 Uhr schrieb Andrey Repin : > Greetings, Stefan Bauer! > > > Hi, > > > > we're running a small relay-service

Re: Best practice - concurrent delivery to remote sites

2018-12-06 Thread Andrey Repin
Greetings, Stefan Bauer! > Hi, > we're running a small relay-service and looking for best practice to > deliver mails to remote sites regarding concurrent delivery and so on. > Sometimes, we have customers that are sending several mails per second to > same recipients. > What is best

Best practice - concurrent delivery to remote sites

2018-12-06 Thread Stefan Bauer
Hi, we're running a small relay-service and looking for best practice to deliver mails to remote sites regarding concurrent delivery and so on. Sometimes, we have customers that are sending several mails per second to same recipients. What is best practice to handle this? We would like to