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" <mailop@mailop.org> 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.9999 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.9999% 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 <large.hadron.colli...@gmx.com>
>
> _______________________________________________
> 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
