headers
Menachem Moystoviz | 1 Sep 2011 16:35
Picon
Picon

Recipient is offline


I apologize in advance if I have violated any norms or rules with this email
After having read the ESMTP RFC(2821) and searching for this problem
on Google, I still don't have an answer.
Suppose one person (Let's call her Alice) wants to send an email to
another (Let's call him Bob).
Now suppose Bob's server is online for 4 hours every day.
According to section 4.5.4.1, Alice's server (or whatever server is
closest to Bob)
should retry sending the mail every half hour or so for 4-5 days,
meaning that Bob will eventually get the mail.
However, experience with Google's Gmail service has showed me that
usually, the server gives up after several seconds.
Is my sample biased or is this the norm, in violation of the RFC?
Moreover, will Bob receive the mail in my example?
Because this would mean that any user who turns his SMTP server on for
a couple of hours each day would receive his mail.

Thank you in advance,

Menachem D. Mostowicz (Gesh)
Permalink | Reply | 52 comments |
headers
Paul Smith | 1 Sep 2011 18:10
Picon
Favicon

Re: Recipient is offline


On 01/09/2011 15:35, Menachem Moystoviz wrote:
> Suppose one person (Let's call her Alice) wants to send an email to
> another (Let's call him Bob).
> Now suppose Bob's server is online for 4 hours every day.
> According to section 4.5.4.1, Alice's server (or whatever server is
> closest to Bob)
> should retry sending the mail every half hour or so for 4-5 days,
> meaning that Bob will eventually get the mail.
> However, experience with Google's Gmail service has showed me that
> usually, the server gives up after several seconds.
> Is my sample biased or is this the norm, in violation of the RFC?
> Moreover, will Bob receive the mail in my example?
> Because this would mean that any user who turns his SMTP server on for
> a couple of hours each day would receive his mail.
>

Well, the sender should retry, but there is no rule about how often or 
for how long it should retry, just a vague suggestion (not even 'SHOULD')

If gmail gives up after a few seconds, then I'm a bit dubious. I'd 
expect it to try longer than that, I'd have thought for at least a day 
(unless it gets a permanent error report back from somewhere).

I'd say that most probably try for 3 days (gives admins chance to fix 
their server after a weekend if it broke on the Friday evening). Busy 
ones like gmail could try less because they have so much mail, and don't 
care as it's a free service. As long as they generate an NDR it's 
compliant with the standard.
(Continue reading)

Permalink | Reply | 39 comments |
headers
Murray S. Kucherawy | 2 Sep 2011 01:14

RE: Recipient is offline


 -----Original Message-----
> From: owner-ietf-smtp <at> mail.imc.org [mailto:owner-ietf-smtp <at> mail.imc.org] On Behalf Of Paul Smith
> Sent: Thursday, September 01, 2011 9:10 AM
> To: Menachem Moystoviz
> Cc: ietf-smtp <at> imc.org
> Subject: Re: Recipient is offline
> 
> On 01/09/2011 15:35, Menachem Moystoviz wrote:
> > Suppose one person (Let's call her Alice) wants to send an email to
> > another (Let's call him Bob).

Yes, I've seen them around.

> > However, experience with Google's Gmail service has showed me that
> > usually, the server gives up after several seconds.

I'm almost certain that's not the case.  I would be surprised to see Gmail tries and gives up only a couple of
times in a short period.

> > Is my sample biased or is this the norm, in violation of the RFC?

The RFC (5321 replaced 2821, by the way), but as Paul points out there's no normative requirement to try a
specific number of times or for a specific duration, just some guidelines.

> > Moreover, will Bob receive the mail in my example?

More than likely.

> > Because this would mean that any user who turns his SMTP server on for
(Continue reading)

Permalink | Reply | 2 comments |
headers
Mark Andrews | 2 Sep 2011 01:32

Re: Recipient is offline


In message <4E5FAE64.2060809 <at> pscs.co.uk>, Paul Smith writes:
> 
> On 01/09/2011 15:35, Menachem Moystoviz wrote:
> > Suppose one person (Let's call her Alice) wants to send an email to
> > another (Let's call him Bob).
> > Now suppose Bob's server is online for 4 hours every day.
> > According to section 4.5.4.1, Alice's server (or whatever server is
> > closest to Bob)
> > should retry sending the mail every half hour or so for 4-5 days,
> > meaning that Bob will eventually get the mail.
> > However, experience with Google's Gmail service has showed me that
> > usually, the server gives up after several seconds.
> > Is my sample biased or is this the norm, in violation of the RFC?
> > Moreover, will Bob receive the mail in my example?
> > Because this would mean that any user who turns his SMTP server on for
> > a couple of hours each day would receive his mail.
> >
> 
> Well, the sender should retry, but there is no rule about how often or 
> for how long it should retry, just a vague suggestion (not even 'SHOULD')
> 
> If gmail gives up after a few seconds, then I'm a bit dubious. I'd 
> expect it to try longer than that, I'd have thought for at least a day 
> (unless it gets a permanent error report back from somewhere).
> 
> I'd say that most probably try for 3 days (gives admins chance to fix 
> their server after a weekend if it broke on the Friday evening). Busy 
> ones like gmail could try less because they have so much mail, and don't 
> care as it's a free service. As long as they generate an NDR it's
(Continue reading)

Permalink | Reply | 34 comments |
headers
Hector Santos | 2 Sep 2011 02:27

Re: Recipient is offline


Paul Smith wrote:

> Well, the sender should retry, but there is no rule about how often or 
> for how long it should retry, just a vague suggestion (not even 'SHOULD')
> 
> If gmail gives up after a few seconds, then I'm a bit dubious. I'd 
> expect it to try longer than that, I'd have thought for at least a day 
> (unless it gets a permanent error report back from somewhere).

Well, I have seen it number of time with non 24x7 SMTP customers 
complaining about not getting mail and we found out that the senders 
did retry - to a 2nd MX the customer had no idea was active, like his 
ISP MX and from there it went no where.

So its possible Google tried to connect to his MX, failed, tried the 
2nd MX and the transaction was done.  Bob will never see it. :)

--

-- 
Sincerely

Hector Santos
http://www.santronics.com
Permalink | Reply | 0 comments |
headers
John C Klensin | 2 Sep 2011 03:04

Re: Recipient is offline


--On Friday, September 02, 2011 09:32 +1000 Mark Andrews
<marka <at> isc.org> wrote:

>> However, if a mail server is online for only a few hours a
>> day, then I'd  seriously suggest getting a backup mail server
>> to accept messages during  the downtime (or putting the main
>> mail server somewhere else with a  better connection), unless
>> you don't really care about getting mail...
> 
> And poll when coming online using TURN after authenticating.
> 
> Also if you do this you should ensure that your backup MX can
> reject non valid addresses or you will generate a lot of
> backscatter. There are a number of different techniques that
> can be used to do this.

That is one of several reasons why TURN was deprecated years ago.

:-(

   john
Permalink | Reply | 33 comments |
headers
John C Klensin | 2 Sep 2011 03:03

RE: Recipient is offline


--On Thursday, September 01, 2011 16:14 -0700 "Murray S.
Kucherawy" <msk <at> cloudmark.com> wrote:

>...
>> > Because this would mean that any user who turns his SMTP
>> > server on for a couple of hours each day would receive his
>> > mail.
> 
> As long as there's a retry during that window, yes.  But that
> isn't guaranteed.

And, if the sender is doing with 5321 (and 2821 and 1123)
suggest (I'm not going to have a discussion about what is and is
not normative in 5321, at least today), the odds of a
rarely-available receiver getting delivery go down rapidly with
time.  Even if the sender keeps trying for more than the
recommended 4-5 days, incremental back off strategies may make a
short receiver-online connection period an increasingly elusive
target.  

See the discussion in RFC 5321, Section 4.5.4.1, for additional
hints about this or, as others have suggested, seriously
consider an intermediate server that is usually or always on-net
and a mechanism for working with it when your
intermittently-connected host is online.  Those could be as
simple as having the intermediate server know the typical
schedule for the intermittent host being online as well as
mechanisms like ETRN or pinging the intermediate with some sort
of message.
(Continue reading)

Permalink | Reply | 1 comment |
headers
Hector Santos | 2 Sep 2011 03:57

Re: Recipient is offline


John C Klensin wrote:
> --On Friday, September 02, 2011 09:32 +1000 Mark Andrews
> <marka <at> isc.org> wrote:
> 
>>> However, if a mail server is online for only a few hours a
>>> day, then I'd  seriously suggest getting a backup mail server
>>> to accept messages during  the downtime (or putting the main
>>> mail server somewhere else with a  better connection), unless
>>> you don't really care about getting mail...
>> And poll when coming online using TURN after authenticating.
>>
>> Also if you do this you should ensure that your backup MX can
>> reject non valid addresses or you will generate a lot of
>> backscatter. There are a number of different techniques that
>> can be used to do this.
> 
> That is one of several reasons why TURN was deprecated years ago.
> 
> :-(

John,  the natives are coming back!  Just in the last 2-3 weeks, at 
least 5-6 people have setup SMTP for non 24x7 operations. Asking the 
same related questions. The economy has forced many to set up SOHO 
shops and are using the new powerful IPTV high speeds setups.

Just had one today where I think he will need us to be his PORT 587 
SMART HOST to get around PORT 25 outbound restrictions.  We allow ETRN 
here and for the operator to use in local mode to start sending 
specific queues.
(Continue reading)

Permalink | Reply | 0 comments |
headers
Mark Andrews | 2 Sep 2011 04:44

Re: Recipient is offline


In message <D25FD080201FAC0F622B58D1 <at> PST.JCK.COM>, John C Klensin writes:
> 
> 
> 
> --On Friday, September 02, 2011 09:32 +1000 Mark Andrews
> <marka <at> isc.org> wrote:
> 
> >> However, if a mail server is online for only a few hours a
> >> day, then I'd  seriously suggest getting a backup mail server
> >> to accept messages during  the downtime (or putting the main
> >> mail server somewhere else with a  better connection), unless
> >> you don't really care about getting mail...
> > 
> > And poll when coming online using TURN after authenticating.
> > 
> > Also if you do this you should ensure that your backup MX can
> > reject non valid addresses or you will generate a lot of
> > backscatter. There are a number of different techniques that
> > can be used to do this.
> 
> That is one of several reasons why TURN was deprecated years ago.

TURN is useful if the is not a direct incoming path.
e.g. Running multiple MTA's behind a firewall/nat that blocks incoming
connections.
ETRN is useful if the is a direct incoming path.

Horses for courses.  That said ETRN is probably more applicable
here as there is a direct incoming path.
(Continue reading)

Permalink | Reply | 31 comments |
headers
Hector Santos | 2 Sep 2011 07:17

Re: Recipient is offline


Mark Andrews wrote:

> Horses for courses.  That said ETRN is probably more applicable
> here as there is a direct incoming path.

+1.  It helps support impatience operators who can't wait for the next 
hour :)

--

-- 
Sincerely

Hector Santos
http://www.santronics.com
Permalink | Reply | 1 comment |

Gmane