Re: [mailop] How long to retry?
In article you write: >Brandon Long via mailop writes: > >> A 5-10 minute delay for us is already in the realm of the second retry >> and pretty unusual unless something's going on. > >OK, so maybe nowadays we ought to have that first NDR (the "for some >reason, I couldn't deliver this right away, but I'll keep trying" one) >after, say, 10 minutes (or when the second retry fails, but that'll >probably require modifying the MTA), and then keep trying for 5 days? In my experience, messages like that just confuse people. They think it's saying they did something wrong, or that the message has been refused or something. You can't win. ___ mailop mailing list mailop@mailop.org https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop
Re: [mailop] How long to retry?
Brandon Long via mailop writes: > A 5-10 minute delay for us is already in the realm of the second retry > and pretty unusual unless something's going on. OK, so maybe nowadays we ought to have that first NDR (the "for some reason, I couldn't deliver this right away, but I'll keep trying" one) after, say, 10 minutes (or when the second retry fails, but that'll probably require modifying the MTA), and then keep trying for 5 days? With Postfix, the above would be: delay_warning_time = 10m # default is 0h, i.e. disabled maximal_queue_lifetime = 5d # this is the default ...and maybe even: confirm_delay_cleared = yes # if delay warning given, inform when sent -tih -- Most people who graduate with CS degrees don't understand the significance of Lisp. Lisp is the most important idea in computer science. --Alan Kay ___ mailop mailing list mailop@mailop.org https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop
Re: [mailop] How long to retry?
On 4 Feb 2020, at 11:43, Brandon Long via mailop wrote: The problem is, user's get used to the performance they get. It's not a question of user education or worse users. If you typically deliver messages in seconds, eventually that's what they expect. Great summary! And, there are different use cases. Some of the mail flows I manage, include messages that are ideally delivered within a couple hour window. Outside that window, the usefulness of said email greatly diminishes. Some others involve more relaxed restrictions. The challenges of both pale by many shades of white vs what I can only imagine are Google-scale constraints. I think there isn't a single solution for all. It's our job as email (postmasters|architects|janitors) to identify which parameters work best for our specific use cases. Some are bound to be harder than others. And hopefully we won't forget that at times, things will break and it will be us fighting the clock to recover the damn mail server. Best regards -lem ___ mailop mailing list mailop@mailop.org https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop
Re: [mailop] How long to retry?
The problem is, user's get used to the performance they get. It's not a
question of user education
or worse users. If you typically deliver messages in seconds, eventually
that's what they expect.
You can tell them otherwise, but people get used to what normally happens.
A 5-10 minute delay for us is already in the realm of the second retry and
pretty unusual unless
something's going on.
Brandon
On Tue, Feb 4, 2020 at 4:09 AM Large Hadron Collider via mailop <
mailop@mailop.org> wrote:
> The 1st NDR (we will be trying for the next N days) can come in around
> half an
> hour of no delivery. Electronic mail has a delay even when it's working
> properly. That's why it's not called instant messaging. I generally expect
> around a 5 to 10 minute delay on messages. I have the naïve user mindset of
> checking immediately, because I know the delays are usually shorter than I
> expect, but I don't get antsy about deliverability until a big tranche of
> an
> hour has passed.
>
> Having 7 day delivery is better than not having any delivery at all, but
> you do
> need to balance that against disk space concerns.
>
> On Mon, 03 Feb 2020 14:43:35 -0800
> "Luis E. Muñoz via mailop" wrote:
>
> >
> >
> > On 3 Feb 2020, at 14:20, Michael Orlitzky via mailop wrote:
> >
> > > You have problems with 100% of messages 0.0001% of the time -- it's
> > > not
> > > a steady 99. success rate, even though that's what the numbers
> > > look
> > > like if your window is five-years long.
> >
> > Since recently – heh, let's call it 5-6 years – I've observed more
> > and more that senders are unable to connect the first NDR ("your mail is
> > stuck, we're still trying") with their original message. There's some
> > cognitive dissonance at play here. If the bounce is not instantaneous,
> > that NDR is a waste of resources for them. More or less the same happens
> > with the final NDR ("sorry, I give up"), where they seem to be unable to
> > grasp that the message was not delivered.
> >
> > Setting the first NDR too soon tend to cause confusion – and often, a
> > resent of the same message – which does not improve the situation for
> > that specific communication.
> >
> > This issue is, IMO, testament that the email landscape today is far more
> > resilient than 30 years ago. But we still need to accommodate the
> > occasional flooded rack. User expectations are very heavily driven by
> > what happens with 99.% of their email. Can't say I blame them.
> >
> > Personally, I've seen more bounces in the last 3 months due to receivers
> > wanting to do TLSv1.0 than the rest of possible causes, all together.
> > The NDR has helped notice this and make special arrangements. But still,
> > the senders were not entirely aware of what happened to their email
> > during the few hours they remained in our outbound queues.
> >
> > Best regards
> >
> > -lem
> >
> > ___
> > mailop mailing list
> > mailop@mailop.org
> > https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop
>
>
> --
> Large Hadron Collider
>
> ___
> mailop mailing list
> mailop@mailop.org
> https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop
>
___
mailop mailing list
mailop@mailop.org
https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop
Re: [mailop] How long to retry?
On Tue, 4 Feb 2020, Paul Smith via mailop wrote: > In my experience, this is very much the case. NDRs are just treated like > spam for many senders, even if they are written in very simple language. Well, they're written in one language (simple or otherwise). Which is a bit of a problem if you don't speak that one. Jethro. . . . . . . . . . . . . . . . . . . . . . . . . . Jethro R Binks, Network Manager, Information Services Directorate, University Of Strathclyde, Glasgow, UK The University of Strathclyde is a charitable body, registered in Scotland, number SC015263. ___ mailop mailing list mailop@mailop.org https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop
Re: [mailop] How long to retry?
The 1st NDR (we will be trying for the next N days) can come in around half an
hour of no delivery. Electronic mail has a delay even when it's working
properly. That's why it's not called instant messaging. I generally expect
around a 5 to 10 minute delay on messages. I have the naïve user mindset of
checking immediately, because I know the delays are usually shorter than I
expect, but I don't get antsy about deliverability until a big tranche of an
hour has passed.
Having 7 day delivery is better than not having any delivery at all, but you do
need to balance that against disk space concerns.
On Mon, 03 Feb 2020 14:43:35 -0800
"Luis E. Muñoz via mailop" wrote:
>
>
> On 3 Feb 2020, at 14:20, Michael Orlitzky via mailop wrote:
>
> > You have problems with 100% of messages 0.0001% of the time -- it's
> > not
> > a steady 99. success rate, even though that's what the numbers
> > look
> > like if your window is five-years long.
>
> Since recently – heh, let's call it 5-6 years – I've observed more
> and more that senders are unable to connect the first NDR ("your mail is
> stuck, we're still trying") with their original message. There's some
> cognitive dissonance at play here. If the bounce is not instantaneous,
> that NDR is a waste of resources for them. More or less the same happens
> with the final NDR ("sorry, I give up"), where they seem to be unable to
> grasp that the message was not delivered.
>
> Setting the first NDR too soon tend to cause confusion – and often, a
> resent of the same message – which does not improve the situation for
> that specific communication.
>
> This issue is, IMO, testament that the email landscape today is far more
> resilient than 30 years ago. But we still need to accommodate the
> occasional flooded rack. User expectations are very heavily driven by
> what happens with 99.% of their email. Can't say I blame them.
>
> Personally, I've seen more bounces in the last 3 months due to receivers
> wanting to do TLSv1.0 than the rest of possible causes, all together.
> The NDR has helped notice this and make special arrangements. But still,
> the senders were not entirely aware of what happened to their email
> during the few hours they remained in our outbound queues.
>
> Best regards
>
> -lem
>
> ___
> mailop mailing list
> mailop@mailop.org
> https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop
--
Large Hadron Collider
___
mailop mailing list
mailop@mailop.org
https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop
Re: [mailop] How long to retry?
On 04.02.20 11:31, Jaroslaw Rafa via mailop wrote: > However, for big web-based email providers like Google, who tend to have > less educated users ;), it would be a good idea what Brandon already > mentioned here - some way of signalling in the GUI that a particular message > has not yet been sent, but is waiting in the queue. People don't understand why there are unsent messages in their current outbox if they accidentally switched their MUA to offline mode. They won't understand this either. Regards, Thomas Walter -- Thomas Walter Datenverarbeitungszentrale FH Münster - University of Applied Sciences - Corrensstr. 25, Raum B 112 48149 Münster Tel: +49 251 83 64 908 Fax: +49 251 83 64 910 www.fh-muenster.de/dvz/ ___ mailop mailing list mailop@mailop.org https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop
Re: [mailop] How long to retry?
On 03/02/2020 22:43, Luis E. Muñoz via mailop wrote:
Since recently – heh, let's call it 5-6 years – I've observed more and
more that senders are unable to connect the first NDR ("your mail is
stuck, we're still trying") with their original message. There's some
cognitive dissonance at play here. If the bounce is not instantaneous,
that NDR is a waste of resources for them. More or less the same
happens with the final NDR ("sorry, I give up"), where they seem to be
unable to grasp that the message was not delivered.
In my experience, this is very much the case. NDRs are just treated like
spam for many senders, even if they are written in very simple language.
We often get the case where a sender complains that a message wasn't
delivered, and is adamant they didn't receive any error message about it
- then we look in their Trash folder, and there's the NDR.
So, in my view, you need to try for at least 3 days before giving up. If
there's any reasonable chance of getting the message delivered, it
should be.
(Maybe MUAs should (where possible) automatically link NDRs to messages
in the 'Sent' folder, so that the user can see there that the message
hasn't been delivered yet. Maybe if DSN was more widely supported, that
would allow better user feedback as well.)
--
Paul Smith Computer Services
Tel: 01484 855800
Vat No: GB 685 6987 53
Sign up for news & updates at http://www.pscs.co.uk/go/subscribe
___
mailop mailing list
mailop@mailop.org
https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop
Re: [mailop] How long to retry?
Dnia 4.02.2020 o godz. 22:53:00 Mark Foster via mailop pisze: > > I've always made a point of educating people that email is not an SLA'd > service and the odd delay will happen. If people need a fast response they > need an interactive engagement - a phonecall. However, for big web-based email providers like Google, who tend to have less educated users ;), it would be a good idea what Brandon already mentioned here - some way of signalling in the GUI that a particular message has not yet been sent, but is waiting in the queue. -- Regards, Jaroslaw Rafa r...@rafa.eu.org -- "In a million years, when kids go to school, they're gonna know: once there was a Hushpuppy, and she lived with her daddy in the Bathtub." ___ mailop mailing list mailop@mailop.org https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop
Re: [mailop] How long to retry?
> > > On 3 Feb 2020, at 14:04, Brandon Long via mailop wrote: > >> One of the main reasons I don't think we should use such long retries >> is >> that it violates user expectations. Users often treat email as nearly >> instantaneous, because it normally is... so taking hours or days of >> actually failing without any quick indication to the user violates >> that >> expectation. > > This. Expectations have changes *a lot* over the years. > > For some pairs of correspondents, it's ok to wait a couple days for an > email. For others, a message delayed more than a few hours is pointless. > > For bulk outbound email, we tend to see a queue that doesn't drain fast > enough as a sign of trouble. > I've always made a point of educating people that email is not an SLA'd service and the odd delay will happen. If people need a fast response they need an interactive engagement - a phonecall. SMS services are the same. As usual as text-message notifications are, they can and do get delayed in the network sometime. Reasons that emergency services are usually turned out by methods more timely and reliable. I agree that quietly queueing for a reasonable amount of time is a great way to manage outages, so i'm not keen to see a trend toward reducing queue times much lower than they are already. The guy frantically rebuilding the mail-server and reconfiguring it on the fly because backup recovery isn't viable, values knowing that he can liven up the machine and receive his queue 36 hours later. Mark. ___ mailop mailing list mailop@mailop.org https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop
Re: [mailop] How long to retry?
Hi Chris, At 09:52 AM 02-02-2020, Chris Adams via mailop wrote: Just an idle Sunday question... how long do you have your mail server(s) configured to queue and retry messages before bouncing them back to the sender? I use five days. That may need to be tuned if the queue is filling up because of delivery issues. I also use "DELIVERBY" for some messages. Regards, -sm ___ mailop mailing list mailop@mailop.org https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop
Re: [mailop] How long to retry?
On 3 Feb 2020, at 14:20, Michael Orlitzky via mailop wrote:
You have problems with 100% of messages 0.0001% of the time -- it's
not
a steady 99. success rate, even though that's what the numbers
look
like if your window is five-years long.
Since recently – heh, let's call it 5-6 years – I've observed more
and more that senders are unable to connect the first NDR ("your mail is
stuck, we're still trying") with their original message. There's some
cognitive dissonance at play here. If the bounce is not instantaneous,
that NDR is a waste of resources for them. More or less the same happens
with the final NDR ("sorry, I give up"), where they seem to be unable to
grasp that the message was not delivered.
Setting the first NDR too soon tend to cause confusion – and often, a
resent of the same message – which does not improve the situation for
that specific communication.
This issue is, IMO, testament that the email landscape today is far more
resilient than 30 years ago. But we still need to accommodate the
occasional flooded rack. User expectations are very heavily driven by
what happens with 99.% of their email. Can't say I blame them.
Personally, I've seen more bounces in the last 3 months due to receivers
wanting to do TLSv1.0 than the rest of possible causes, all together.
The NDR has helped notice this and make special arrangements. But still,
the senders were not entirely aware of what happened to their email
during the few hours they remained in our outbound queues.
Best regards
-lem
___
mailop mailing list
mailop@mailop.org
https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop
Re: [mailop] How long to retry?
On Mon, Feb 3, 2020 at 2:23 PM Michael Orlitzky via mailop < mailop@mailop.org> wrote: > On 2/3/20 5:04 PM, Brandon Long wrote: > > > > I always wanted to lower it, the messages that take longer than a day > > are in the noise, and a lot of time that's because a mailbox is so busy > > that it's on the edge of being able to actually handle the volume, and > > the problem is more one of flow control (twice in two threads, wow) > > It's easy to lie (inadvertently) with statistics. If you draw the window > big enough, you can ignore any potential problem as statistical noise. > Basically 100% of the time, messages do go through instantaneously. But > when your office floods and you have to call someone in to replace, > reinstall, and restore the whole thing from backup, now 100% of your > messages are delayed. > > You have problems with 100% of messages 0.0001% of the time -- it's not > a steady 99. success rate, even though that's what the numbers look > like if your window is five-years long. > > Customers really love hearing that they're not going to lose any mail > when that happens. The rest of the time, yeah, it's a bit long. But > we're not trying to accomodate the one guy who's over quota on a random > Tuesday. > Sure, but it's still a question of expectations. I mean, if you lost your webserver, your customers won't see your website for days, there's no real "show me the webpage when the server becomes available again" (I mean, on mobile Chrome, it has some level of that if your data connection isn't working, but that's not "days"). Anyways, managing those expectations in both directions is why we never made a change there, and looked at alternative solutions. When you have enough customers, people have every expectation available. ___ mailop mailing list mailop@mailop.org https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop
Re: [mailop] How long to retry?
On 3 Feb 2020, at 14:04, Brandon Long via mailop wrote: One of the main reasons I don't think we should use such long retries is that it violates user expectations. Users often treat email as nearly instantaneous, because it normally is... so taking hours or days of actually failing without any quick indication to the user violates that expectation. This. Expectations have changes *a lot* over the years. For some pairs of correspondents, it's ok to wait a couple days for an email. For others, a message delayed more than a few hours is pointless. For bulk outbound email, we tend to see a queue that doesn't drain fast enough as a sign of trouble. Best regards -lem ___ mailop mailing list mailop@mailop.org https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop
Re: [mailop] How long to retry?
On 2/3/20 5:04 PM, Brandon Long wrote: > > I always wanted to lower it, the messages that take longer than a day > are in the noise, and a lot of time that's because a mailbox is so busy > that it's on the edge of being able to actually handle the volume, and > the problem is more one of flow control (twice in two threads, wow) It's easy to lie (inadvertently) with statistics. If you draw the window big enough, you can ignore any potential problem as statistical noise. Basically 100% of the time, messages do go through instantaneously. But when your office floods and you have to call someone in to replace, reinstall, and restore the whole thing from backup, now 100% of your messages are delayed. You have problems with 100% of messages 0.0001% of the time -- it's not a steady 99. success rate, even though that's what the numbers look like if your window is five-years long. Customers really love hearing that they're not going to lose any mail when that happens. The rest of the time, yeah, it's a bit long. But we're not trying to accomodate the one guy who's over quota on a random Tuesday. ___ mailop mailing list mailop@mailop.org https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop
Re: [mailop] How long to retry?
Some Google services use one day, some use three days. There are some outliers on receiving mail, ie particular users can be hospitalized or temporarily disabled and then retries will go longer. I always wanted to lower it, the messages that take longer than a day are in the noise, and a lot of time that's because a mailbox is so busy that it's on the edge of being able to actually handle the volume, and the problem is more one of flow control (twice in two threads, wow) One of the main reasons I don't think we should use such long retries is that it violates user expectations. Users often treat email as nearly instantaneous, because it normally is... so taking hours or days of actually failing without any quick indication to the user violates that expectation. As much as I'm annoyed in instant messaging apps when they give up in seconds and I have to manually retry, at least they aren't fooling me into thinking the other party has the message. I periodically proposed an "outbox" idea where messages would be very visible with attempt and failure information until the message was accepted by the remote server, but it never made the cut. Brandon On Sun, Feb 2, 2020 at 11:20 AM Tony Patti via mailop wrote: > In addition to "long weekends", I would add "natural disasters". > > As I recall the 5-day-rule came in handy during Hurricane Sandy as well... > > Tony Patti > > -Original Message- > From: mailop On Behalf Of Michael Orlitzky > via mailop > Sent: Sunday, February 2, 2020 1:16 PM > To: mailop@mailop.org > Subject: Re: [mailop] How long to retry? > > On 2/2/20 12:52 PM, Chris Adams via mailop wrote: > > Just an idle Sunday question... how long do you have your mail > > server(s) configured to queue and retry messages before bouncing them > > back to the sender? > > > > I know back in the day, 5 days was the norm, to handle servers that > > were only sometimes connected, outages, etc. > > The five-days number is recommended by the RFCs. I always assumed that > number was to account for "long weekends." If your server crashes on > somebody else's property on Friday, and if Monday is a holiday, you can > still get mail that is retried for 5 days. > > ___ > mailop mailing list > mailop@mailop.org > https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop > > > ___ > mailop mailing list > mailop@mailop.org > https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop > ___ mailop mailing list mailop@mailop.org https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop
Re: [mailop] How long to retry?
In addition to "long weekends", I would add "natural disasters". As I recall the 5-day-rule came in handy during Hurricane Sandy as well... Tony Patti -Original Message- From: mailop On Behalf Of Michael Orlitzky via mailop Sent: Sunday, February 2, 2020 1:16 PM To: mailop@mailop.org Subject: Re: [mailop] How long to retry? On 2/2/20 12:52 PM, Chris Adams via mailop wrote: > Just an idle Sunday question... how long do you have your mail > server(s) configured to queue and retry messages before bouncing them > back to the sender? > > I know back in the day, 5 days was the norm, to handle servers that > were only sometimes connected, outages, etc. The five-days number is recommended by the RFCs. I always assumed that number was to account for "long weekends." If your server crashes on somebody else's property on Friday, and if Monday is a holiday, you can still get mail that is retried for 5 days. ___ mailop mailing list mailop@mailop.org https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop ___ mailop mailing list mailop@mailop.org https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop
Re: [mailop] How long to retry?
On 2/2/20 12:52 PM, Chris Adams via mailop wrote: > Just an idle Sunday question... how long do you have your mail server(s) > configured to queue and retry messages before bouncing them back to the > sender? > > I know back in the day, 5 days was the norm, to handle servers that were > only sometimes connected, outages, etc. The five-days number is recommended by the RFCs. I always assumed that number was to account for "long weekends." If your server crashes on somebody else's property on Friday, and if Monday is a holiday, you can still get mail that is retried for 5 days. ___ mailop mailing list mailop@mailop.org https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop
[mailop] How long to retry?
Just an idle Sunday question... how long do you have your mail server(s) configured to queue and retry messages before bouncing them back to the sender? I know back in the day, 5 days was the norm, to handle servers that were only sometimes connected, outages, etc. I think that's still the default in most software. But that seems really long now. I took a quick look at some of my logs, and out of 4.6 million messages relayed to outside servers, 134 of them took longer than 12 hours. Of the messages that took longer than 1 minute, 77% were relayed within 1 hour (probably greylisting). Of the messages past 1 hour, 80% were relayed within 6 hours. I've got the queue life set to 1 day on some personal servers, but I'm wondering if I should go even shorter. For the most part, users don't really understand warnings and all - they'll be best server by getting a bounce as soon as practical. Anybody know what the big guys (Google and the like) do? I thought about setting up an address to always return 4xx and sending tests, but I'm lazy so I figured I'd ask here instead. :) -- Chris Adams ___ mailop mailing list mailop@mailop.org https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop
