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
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)
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
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
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
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
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
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
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
>
>
> 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
>>
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
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
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 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
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
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
>
o: 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?
>
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
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
19 matches
Mail list logo
