Prev: More timeouts?
Next: sendmail fqdn auth
From: edspyhill01 on 6 Jan 2010 08:58
Does Sendmail define the "normal" range of delivery times/delays? Is
there a stated or implied SLA that states delivery times and
acceptable delay times?

Ed
From: Loki Harfagr on 7 Jan 2010 04:05
Wed, 06 Jan 2010 05:58:34 -0800, edspyhill01 did cat :

> Does Sendmail define the "normal" range of delivery times/delays? Is
> there a stated or implied SLA that states delivery times and acceptable
> delay times?
>
> Ed

The SMTP gives a few recommendations here:
RFC 5321 (2821) 4.5.4.1 Sending Strategy

As for Sendmail the default value is set to 5 days:
--------
$ grep -A 2 'confTO_QUEUERETURN\b' /usr/share/sendmail/cf/README
confTO_QUEUERETURN Timeout.queuereturn
[5d] The timeout before a message is
returned as undeliverable.
--------

which suits very well the RFC ;-)
"
the give-up time generally needs to be at least 4-5 days.
"
From: edspyhill01 on 7 Jan 2010 08:05
On Jan 7, 4:05 am, Loki Harfagr <l...(a)thedarkdesign.free.fr.INVALID>
wrote:
> Wed, 06 Jan 2010 05:58:34 -0800, edspyhill01 did cat :
>
> > Does Sendmail define the "normal" range of delivery times/delays?  Is
> > there a stated or implied SLA that states delivery times and acceptable
> > delay times?
>
> > Ed
>
> The SMTP gives a few recommendations here:
>  RFC 5321 (2821) 4.5.4.1 Sending Strategy
>
> As for Sendmail the default value is set to 5 days:
> --------
> $ grep -A 2 'confTO_QUEUERETURN\b' /usr/share/sendmail/cf/README
> confTO_QUEUERETURN      Timeout.queuereturn
>                                         [5d] The timeout before a message is
>                                         returned as undeliverable.
> --------
>
> which suits very well the RFC ;-)
> "
>  the give-up time generally needs to be at least 4-5 days.
> "

Excellent, Thank you. We've used the 3 day Timeout.queuereturn for as
long as I've been here, Lotus Notes and Sendmail. I wanted to ensure
there wasn't some unofficial delivery goal that should be used.

People assume every single email will take seconds to traverse the
Internet and arrive in their inbox. In a world of ever increasing
Spam and Phishing emails and the filters to deal with all of it, users
must expect some delays. In addition to explaining the realities of
the Internet Email and Spam, explaining at a high level the varied
MUA's and MTA's each email takes, I've been suggesting that "business
critical, time-sensitive emails" should be exchanged over dedicated
lines or VPNs.

Another aspect of this problem is we have outsourced EVERYTHING, so we
now have hundreds of very small companies without resources to deploy
robust Internet SMTP servers sending emails and getting delayed by our
Spam rules.

I'm putting together an internal Help document to explain the
limitations of Internet Email, reasons for those limitations,
reasonable user expectations, and solutions for "business critical,
time-sensitive emails".
From: ska on 8 Jan 2010 04:57
edspyhill01 wrote:
> MUA's and MTA's each email takes, I've been suggesting that "business
> critical, time-sensitive emails" should be exchanged over dedicated
> lines or VPNs.

Hmm.

> Another aspect of this problem is we have outsourced EVERYTHING, so we

Oh :-(

> now have hundreds of very small companies without resources to deploy
> robust Internet SMTP servers sending emails and getting delayed by our
> Spam rules.

> I'm putting together an internal Help document to explain the
> limitations of Internet Email, reasons for those limitations,
> reasonable user expectations, and solutions for "business critical,
> time-sensitive emails".

If the problems are mostly the incoming mails, depending on your needs
and the remote partners:

1) you could deploy other strategies besides VPN, such as instant
messaging, e.g. Jabber. There ought to be mail<->jabber gateways you
can run in-house for local users.

2) let have them sign their mails with PGP/GPG. You then whitelist
particular keys in-house bypassing certain delays.

-ska
 | 
Pages: 1
Prev: More timeouts?
Next: sendmail fqdn auth