Whenever I send an e-mail with an attachment from my email account to a
Yahoo address, it takes 1-2 days to show up in the recepient's inbox.
Only Yahoo, only with an attachment, and only when sending through my
domain name. It doesn't get spam blocked it just takes a really long
time to arrive.
My hosting company says they have no idea why or how that could be
happening.
Any ideas?
G
Grip wrote:
> Whenever I send an e-mail with an attachment from my email account to a
> Yahoo address, it takes 1-2 days to show up in the recepient's inbox.
> Only Yahoo, only with an attachment, and only when sending through my
> domain name. It doesn't get spam blocked it just takes a really long
> time to arrive.
>
> My hosting company says they have no idea why or how that could be
> happening.
>
> Any ideas?
>
> G
>
Hmm.
Without the header information it is impossible to answer your question.
The three entities that can be at fault are your the firm through whom
you send the message, the receiving (yahoo) or you (if you only queued
the message, but did not actually send it)
One way to determine the cause for the delay is to look at the full
message headers and see between which hopes (mail server to mail server)
the message was delayed. once you see where the mailing was delayed you
could proceed with dealing with the entity.
AK
I sent my hosting company the header from my e-mail. I've included the
relevant "recevied lines" but xxx out any info that might compromise my
security. Below that is the e-mail response I received from my tech
support. Are they just passing the buck?
Thanks
G
> Received: from 206.221.211.94 (EHLO bh1.la1.xxhostxx.com)
> (206.221.211.94) by mta262.mail.re2.yahoo.com with SMTP; Fri, 09 Jun
> 2006 01:25:56 -0700
> ****
> Received: by bh1.la1.xxhostingcoxx.com (CommuniGate Pro PIPE 3.5.9) with PIPE id
> 336413586; Thu, 08 Jun 2006 12:08:03 -0700
> ****
> Received: from [xx.xx.xx.xx] by bh1.la1.xxhostingcoxx.com
> (CommuniGate Pro SMTP 3.5.9) with ESMTP id 336413421; Thu, 08 Jun 2006
> 12:07:40 -0700
I've spoken with my NOC guys who deal with yahoo and here is there
response with respect to their being a 12 hour delay for the delivery::
Delays can occur because of the destination mail servers timing out,
either because of an internet connection, or because it is planned, and
in this instance that is the case. Yahoo has always been quite
aggressive with filters and therefore mail going to them has always
been anything other than rock solid. You cant blame them since it is a
free email service.
There will always be delays going to yahoo, until they change their
filtering.
As far as emails through other accounts getting through more quickly,
it's likely
that Yahoos filtering targets non-isp emails more agressively than ISP
emails. Your other account Cybermesa is a known ISP, and their filters
may treat
differently a mail sent from a website mail server (mail servers are
where spam is generated from. ISP's don't allow the sending of spam -
they institute max recipients, max sizes and other methods that limit
what and how a user can send... Our mail servers do not restrict what
and how much can be sent, Yahoo knows this so they look at mail from
such sources with greater scrutiny)
As to the actual specifics of how Yahoo filters and targets, you would
need to contact yahoo directly. We can only make educated and fairly
informed guesses.
Additionally the path from the mail server to Yahoo is different from
the path takes, so it's very very difficult to compare. Different
networks, different
paths, different things going on from one moment to the next.
In short, the delivery on the email headers you sent timed out as did
the the following 2 attempts (attempts are made every four hours up to
4 days). The fourth attempt was successful and the mail was delivered.
AK wrote:
> Grip wrote:
>
> > Whenever I send an e-mail with an attachment from my email account to a
> > Yahoo address, it takes 1-2 days to show up in the recepient's inbox.
> > Only Yahoo, only with an attachment, and only when sending through my
> > domain name. It doesn't get spam blocked it just takes a really long
> > time to arrive.
> >
> > My hosting company says they have no idea why or how that could be
> > happening.
> >
> > Any ideas?
> >
> > G
> >
> Hmm.
>
> Without the header information it is impossible to answer your question.
> The three entities that can be at fault are your the firm through whom
> you send the message, the receiving (yahoo) or you (if you only queued
> the message, but did not actually send it)
>
>
> One way to determine the cause for the delay is to look at the full
> message headers and see between which hopes (mail server to mail server)
> the message was delayed. once you see where the mailing was delayed you
> could proceed with dealing with the entity.
>
> AK
On 13 Jun 2006 07:18:04 -0700, "Grip"
>I sent my hosting company the header from my e-mail. I've included the
>relevant "recevied lines" but xxx out any info that might compromise my
>security. Below that is the e-mail response I received from my tech
>support. Are they just passing the buck?
It looks like they "spiced it up" a bit, but the ultimate explanation
that it took several tries to deliver to Yahoo sounds very reasonable.
Especially since they seem to have checked their logs and counted the
number of tries it took. The stuff about "different networks" and
"different paths" is BS. The stuff about Yahoo's spam filters could be
plausible. They don't say exactly what "timed out". It could be that
their server "timed out" waiting for a response from Yahoo after they had
sent the body of the email... and the reason for that could be that Yahoo
took a while deciding whether or not it wanted to accept that email
(because of the size of the email and consequent processing time). Or
maybe Yahoo does Greylisting, which requires retries, but 11 hours sounds
like a long time for that. But, that could account for the different
performance for different senders; Sender A gets Greylisted, Sender B
doesn't. Along those lines, it could also be, like they said, that some
senders have their email more closely scrutinized than others.
Nothing I came up with really seems to nail it, I just felt like
tossing out some ideas. A relatively short "time out" on their server
waiting for a response seems most likely. Eventually their server would
retry when Yahoo wasn't so busy, so the processing would go faster, and
the "time out" wouldn't happen. Do you always send those attachments at
roughly the same time of day? 7 PM on the west coast is probably a very
busy time of day.
Just purely guessing,
Steve Baker
>Thanks
>G
>
>> Received: from 206.221.211.94 (EHLO bh1.la1.xxhostxx.com)
>> (206.221.211.94) by mta262.mail.re2.yahoo.com with SMTP; Fri, 09 Jun
>> 2006 01:25:56 -0700
>> ****
>> Received: by bh1.la1.xxhostingcoxx.com (CommuniGate Pro PIPE 3.5.9) with PIPE id
>> 336413586; Thu, 08 Jun 2006 12:08:03 -0700
>> ****
>> Received: from [xx.xx.xx.xx] by bh1.la1.xxhostingcoxx.com
>> (CommuniGate Pro SMTP 3.5.9) with ESMTP id 336413421; Thu, 08 Jun 2006
>> 12:07:40 -0700
>
>
>I've spoken with my NOC guys who deal with yahoo and here is there
>response with respect to their being a 12 hour delay for the delivery::
>
>Delays can occur because of the destination mail servers timing out,
>either because of an internet connection, or because it is planned, and
>in this instance that is the case. Yahoo has always been quite
>aggressive with filters and therefore mail going to them has always
>been anything other than rock solid. You cant blame them since it is a
>free email service.
>
>There will always be delays going to yahoo, until they change their
>filtering.
>
>As far as emails through other accounts getting through more quickly,
>it's likely
>that Yahoos filtering targets non-isp emails more agressively than ISP
>emails. Your other account Cybermesa is a known ISP, and their filters
>may treat
>differently a mail sent from a website mail server (mail servers are
>where spam is generated from. ISP's don't allow the sending of spam -
>they institute max recipients, max sizes and other methods that limit
>what and how a user can send... Our mail servers do not restrict what
>and how much can be sent, Yahoo knows this so they look at mail from
>such sources with greater scrutiny)
>
>As to the actual specifics of how Yahoo filters and targets, you would
>need to contact yahoo directly. We can only make educated and fairly
>informed guesses.
>
>Additionally the path from the mail server to Yahoo is different from
>the path takes, so it's very very difficult to compare. Different
>networks, different
>paths, different things going on from one moment to the next.
>
>In short, the delivery on the email headers you sent timed out as did
>the the following 2 attempts (attempts are made every four hours up to
>
>4 days). The fourth attempt was successful and the mail was delivered.
>
>
>AK wrote:
>> Grip wrote:
>>
>> > Whenever I send an e-mail with an attachment from my email account to a
>> > Yahoo address, it takes 1-2 days to show up in the recepient's inbox.
>> > Only Yahoo, only with an attachment, and only when sending through my
>> > domain name. It doesn't get spam blocked it just takes a really long
>> > time to arrive.
>> >
>> > My hosting company says they have no idea why or how that could be
>> > happening.
>> >
>> > Any ideas?
>> >
>> > G
>> >
>> Hmm.
>>
>> Without the header information it is impossible to answer your question.
>> The three entities that can be at fault are your the firm through whom
>> you send the message, the receiving (yahoo) or you (if you only queued
>> the message, but did not actually send it)
>>
>>
>> One way to determine the cause for the delay is to look at the full
>> message headers and see between which hopes (mail server to mail server)
>> the message was delayed. once you see where the mailing was delayed you
>> could proceed with dealing with the entity.
>>
>> AK
--
Steve Baker
Steve Baker wrote:
> On 13 Jun 2006 07:18:04 -0700, "Grip"
>
>
>>I sent my hosting company the header from my e-mail. I've included the
>>relevant "recevied lines" but xxx out any info that might compromise my
>>security. Below that is the e-mail response I received from my tech
>>support. Are they just passing the buck?
>
>
> It looks like they "spiced it up" a bit, but the ultimate explanation
> that it took several tries to deliver to Yahoo sounds very reasonable.
> Especially since they seem to have checked their logs and counted the
> number of tries it took. The stuff about "different networks" and
> "different paths" is BS. The stuff about Yahoo's spam filters could be
> plausible. They don't say exactly what "timed out". It could be that
> their server "timed out" waiting for a response from Yahoo after they had
> sent the body of the email... and the reason for that could be that Yahoo
> took a while deciding whether or not it wanted to accept that email
> (because of the size of the email and consequent processing time). Or
> maybe Yahoo does Greylisting, which requires retries, but 11 hours sounds
> like a long time for that. But, that could account for the different
> performance for different senders; Sender A gets Greylisted, Sender B
> doesn't. Along those lines, it could also be, like they said, that some
> senders have their email more closely scrutinized than others.
> Nothing I came up with really seems to nail it, I just felt like
> tossing out some ideas. A relatively short "time out" on their server
> waiting for a response seems most likely. Eventually their server would
> retry when Yahoo wasn't so busy, so the processing would go faster, and
> the "time out" wouldn't happen. Do you always send those attachments at
> roughly the same time of day? 7 PM on the west coast is probably a very
> busy time of day.
>
> Just purely guessing,
> Steve Baker
>
>
>>Thanks
>>G
>>
>>
>>>Received: from 206.221.211.94 (EHLO bh1.la1.xxhostxx.com)
>>>(206.221.211.94) by mta262.mail.re2.yahoo.com with SMTP; Fri, 09 Jun
>>>2006 01:25:56 -0700
>>>****
>>>Received: by bh1.la1.xxhostingcoxx.com (CommuniGate Pro PIPE 3.5.9) with PIPE id
>>>336413586; Thu, 08 Jun 2006 12:08:03 -0700
>>>****
>>>Received: from [xx.xx.xx.xx] by bh1.la1.xxhostingcoxx.com
>>>(CommuniGate Pro SMTP 3.5.9) with ESMTP id 336413421; Thu, 08 Jun 2006
>>>12:07:40 -0700
>>
>>
>>I've spoken with my NOC guys who deal with yahoo and here is there
>>response with respect to their being a 12 hour delay for the delivery::
>>
>>Delays can occur because of the destination mail servers timing out,
>>either because of an internet connection, or because it is planned, and
>>in this instance that is the case. Yahoo has always been quite
>>aggressive with filters and therefore mail going to them has always
>>been anything other than rock solid. You cant blame them since it is a
>>free email service.
>>
>>There will always be delays going to yahoo, until they change their
>>filtering.
>>
>>As far as emails through other accounts getting through more quickly,
>>it's likely
>>that Yahoos filtering targets non-isp emails more agressively than ISP
>>emails. Your other account Cybermesa is a known ISP, and their filters
>>may treat
>>differently a mail sent from a website mail server (mail servers are
>>where spam is generated from. ISP's don't allow the sending of spam -
>>they institute max recipients, max sizes and other methods that limit
>>what and how a user can send... Our mail servers do not restrict what
>>and how much can be sent, Yahoo knows this so they look at mail from
>>such sources with greater scrutiny)
>>
>>As to the actual specifics of how Yahoo filters and targets, you would
>>need to contact yahoo directly. We can only make educated and fairly
>>informed guesses.
>>
>>Additionally the path from the mail server to Yahoo is different from
>>the path takes, so it's very very difficult to compare. Different
>>networks, different
>>paths, different things going on from one moment to the next.
>>
>>In short, the delivery on the email headers you sent timed out as did
>>the the following 2 attempts (attempts are made every four hours up to
>>
>>4 days). The fourth attempt was successful and the mail was delivered.
>>
>>
>>AK wrote:
>>
>>>Grip wrote:
>>>
>>>
>>>>Whenever I send an e-mail with an attachment from my email account to a
>>>>Yahoo address, it takes 1-2 days to show up in the recepient's inbox.
>>>>Only Yahoo, only with an attachment, and only when sending through my
>>>>domain name. It doesn't get spam blocked it just takes a really long
>>>>time to arrive.
>>>>
>>>>My hosting company says they have no idea why or how that could be
>>>>happening.
>>>>
>>>>Any ideas?
>>>>
>>>>G
>>>>
>>>
>>>Hmm.
>>>
>>>Without the header information it is impossible to answer your question.
>>>The three entities that can be at fault are your the firm through whom
>>>you send the message, the receiving (yahoo) or you (if you only queued
>>>the message, but did not actually send it)
>>>
>>>
>>>One way to determine the cause for the delay is to look at the full
>>>message headers and see between which hopes (mail server to mail server)
>>>the message was delayed. once you see where the mailing was delayed you
>>>could proceed with dealing with the entity.
>>>
>>>AK
>
>
>
I would agee with Steve. Usually if the sending server reaches the time
wait threshold and disconnects, the recipient will likely get duplicates
since the message was actually delivered to the receiving server, but
the sending server had not received the status message for the delivery.
The requeing or the redelivery attempt depends on each sending server.
Some have automatic scheduler and some, primarily batch type queues,
will attempt redelivery on a set schedule.
With the filtering, one should allow for up to 10 minutes prior to
disconnecting. The likely config on the mail servers prior to spam
(dark ages) was to have the timeout at 2 minutes.
Since you brought this matter to the attention of your NOC, hopefully
they increased the timeout for the SMTP session.
If you want to experiment, you could send emails with attachments of
various sizes. Using that you can narrow down at which message size you
might encounter delays due to processing/originating server's timeout.
AK
On Wed, 14 Jun 2006 06:02:34 -0400, AK
>I would agee with Steve. Usually if the sending server reaches the time
>wait threshold and disconnects, the recipient will likely get duplicates
> since the message was actually delivered to the receiving server, but
>the sending server had not received the status message for the delivery.
Hmm. Really? The receiving server doesn't need to see a quit or rset
before it decides that the Data it saw was the real deal?
--
Steve Baker
Steve Baker wrote:
> On Wed, 14 Jun 2006 06:02:34 -0400, AK
>
>
>>I would agee with Steve. Usually if the sending server reaches the time
>>wait threshold and disconnects, the recipient will likely get duplicates
>> since the message was actually delivered to the receiving server, but
>>the sending server had not received the status message for the delivery.
>
>
> Hmm. Really? The receiving server doesn't need to see a quit or rset
> before it decides that the Data it saw was the real deal?
>
Yes, really. The receiving server does not wait for the rset or quit,
to process a message.
the process is:
helo
2xx
mail from
2xx
rcpt to
2xx
data
3xx
some message
data in the correct format
..
Once the receiving server gets the message data terminating
message (filters what have you). During this stage the receiving server
is not expecting any further input from the sending server. All that is
left to complete this transaction is for the receiving server to provide
the status code for the transaction to the sending server 2xx good; 4xx
try again later; 5xx bad go away.
Had a situation where the SMTP client timmeout threshold for connections
(smtp server's outgoing connections) was set too low such that the
sending server kept disconnecting, but the message was being delivered
every single time to the recipient.
AK
On Wed, 14 Jun 2006 18:13:27 -0400, AK
....
>> Hmm. Really? The receiving server doesn't need to see a quit or rset
>> before it decides that the Data it saw was the real deal?
>>
>
>Yes, really. The receiving server does not wait for the rset or quit,
Hmm. What the hell was I thinking. I feel silly now. Yeah, it needs to
see the ending ".".
....
>Had a situation where the SMTP client timmeout threshold for connections
>(smtp server's outgoing connections) was set too low such that the
>sending server kept disconnecting, but the message was being delivered
>every single time to the recipient.
Which is kinda the opposite of what's happening here. Hmm. Maybe the
receiver sends "RWIN=0" while it's doing some processing so that it
doesn't see the entire Data before the sender times out? I see that when
my news client is decoding binaries while downloading (P-150 ;-)). Could
that happen at Yahoo if it's "too busy"?
--
Steve Baker
Steve Baker wrote:
> On Wed, 14 Jun 2006 18:13:27 -0400, AK
>
> ...
>
>>> Hmm. Really? The receiving server doesn't need to see a quit or rset
>>>before it decides that the Data it saw was the real deal?
>>>
>>
>>Yes, really. The receiving server does not wait for the rset or quit,
>
>
> Hmm. What the hell was I thinking. I feel silly now. Yeah, it needs to
> see the ending ".".
> ...
>
>>Had a situation where the SMTP client timmeout threshold for connections
>>(smtp server's outgoing connections) was set too low such that the
>>sending server kept disconnecting, but the message was being delivered
>>every single time to the recipient.
>
>
> Which is kinda the opposite of what's happening here. Hmm. Maybe the
> receiver sends "RWIN=0" while it's doing some processing so that it
> doesn't see the entire Data before the sender times out? I see that when
> my news client is decoding binaries while downloading (P-150 ;-)). Could
> that happen at Yahoo if it's "too busy"?
>
Without seeing the complete log of the smtp interaction, there is no way
to know whether during the SMTP session, the sending server sent a
command, but thereceiving server did not see it. If a server is busy or
under the "weather", it could take some time to respond and might reach
the sending server's IDLE TIMEOUT threshold. The only way to check is
to see to which mail server (IP) the server connected and see whether
said server takes its time to respond to different SMTP commands.
AK