Delivering Large e-Mail to Yahoo Fails

Ruler2112

Ruler2112

I'm having troubles. Apologies in advance for the choppy posting - posts are limited to 10,000 characters and I've been troubleshooting quite a bit.



The Problem
Any message that is sent to any user at yahoo.com that has an attachment more than a meg or two will get stuck in my delivery queue for about a week and never be delivered to it's destination. I've been seeing these errors in my e-mailed cron report and decided to investigate.



Troubleshooting

A co-worker of mine has a yahoo account and I sent her a couple of test messages as a way to try to isolate the problem.

Test 1 was a simple text message with no attachment - this zipped right through and she got it almost immediately.

Test 2 was again a simple text message only with our company logo as a 5.8 meg TIFF file attached. This is still stuck in my mail queue and she's not seen anything.

This happens ONLY with a yahoo user as the message recipient. I've tried sending big files to various other mail providers (gmail, fastmail, mac, other corporate servers, my home ISP server) and there are no problems whatsoever. I've sent files up to 15 meg and my boss has sent near 25 meg ad sample videos to several people at the same time (the reason I implemented ALTQ ;) :e ) with no trouble at all, so long as the person we're sending them to is NOT using yahoo as a mail provider. I sent the same 2 test messages to another co-worker's gmail account at basically the same time and they both went through without any trouble. A message from yahoo to my server with the same 5.8 meg TIFF file attached goes through fine. Because of this, I tend to believe the problem either resides with the yahoo mail servers or is due to some strange interaction between my server/ISP and theirs. Quite honestly, I don't care where the problem is as long as it can be found and fixed.

I opened a case with the yahoo postmasters and tried discussing the problem with them. In short, they don't want to hear it and basically won't do anything to help, not even look in their mail logs to see if there's possibly a more descriptive error than the 'lost connection' I'm getting. (After sending the details below and more uncensored, one guy told me to manually connect to the yahoo server with telnet and provide him with the entire SMTP conversation up to and including the error. Yeah, I can type base64 fast & accurately enough for that. ;) It makes me wonder if he actually read the message I sent...) Without having access to the logs on the yahoo mail servers so that I can look and try to figure out what's going on, I'm out of ideas of what to even try.

Given that it says lost connection....while sending end of data, would this indicate that the message is sent and for some reason is bombing out when the .\n is sent? (Yes, I'm really grasping at straws here. ;) I'm just trying to come up with something/anything logical or semi-logical that might explain this that I could use to troubleshoot/fix whatever is causing the problem.)
 
Test Message Results

Code: 
------ Start of source of message Test 1 as sent from Thunderbird ------------
From - Tue Mar 02 15:50:34 2010
X-Mozilla-Status: 0001
X-Mozilla-Status2: 00800000
Message-ID: <4B8D7A18.4020100@mydomain.com>
Date: Tue, 02 Mar 2010 15:50:32 -0500
From: My Name <myaddress@mydomain.com>
User-Agent: Thunderbird 1.5.0.9 (X11/20061206)
MIME-Version: 1.0
To: Home- A Coworker <heraddress@yahoo.com>
Subject: Test Message 1
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

This is a test of a normal, text-only message with no attachment.

Jim




------- End of source of message Test 1 as sent from Thunderbird -------------


------ Start of /var/log/maillog on mail server for Test Message 1 -----------
Mar  2 15:50:32 mydomain postfix/smtpd[13879]: 6D7AD14206D: client=unknown[myip], sasl_method=PLAIN, sasl_username=myaddress
Mar  2 15:50:32 mydomain postfix/cleanup[87299]: 6D7AD14206D: message-id=<4B8D7A18.4020100@mydomain.com>
Mar  2 15:50:32 mydomain postfix/qmgr[68684]: 6D7AD14206D: from=<myaddress@mydomain.com>, size=628, nrcpt=1 (queue active)
Mar  2 15:50:32 mydomain postfix/smtpd[13879]: disconnect from unknown[myip]
Mar  2 15:50:32 mydomain postfix/smtpd[90049]: C289314206E: client=localhost[127.0.0.1]
Mar  2 15:50:32 mydomain postfix/cleanup[87299]: C289314206E: message-id=<4B8D7A18.4020100@mydomain.com>
Mar  2 15:50:32 mydomain postfix/smtpd[90049]: disconnect from localhost[127.0.0.1]
Mar  2 15:50:32 mydomain amavis[53771]: (53771-02) Passed CLEAN, [myip] [myip] <myaddress@mydomain.com> -> <heraccount@yahoo.com>, Message-ID: 
<4B8D7A18.4020100@mydomain.com>, mail_id: MoL356qUYXCi, Hits: -, size: 628, queued_as: C289314206E, 214 ms
Mar  2 15:50:32 mydomain postfix/qmgr[68684]: C289314206E: from=<myaddress@mydomain.com>, size=1072, nrcpt=1 (queue active)
Mar  2 15:50:32 mydomain postfix/smtp[88349]: 6D7AD14206D: to=<heracount@yahoo.com>, relay=127.0.0.1[127.0.0.1]:10024, delay=0.44, 
delays=0.21/0/0.01/0.22, dsn=2.0.0, status=sent (250 2.0.0 from MTA([127.0.0.1]:10025): 250 2.0.0 Ok: queued as C289314206E)
Mar  2 15:50:32 mydomain postfix/qmgr[68684]: 6D7AD14206D: removed
Mar  2 15:50:33 mydomain postfix/smtp[20782]: C289314206E: to=<heraccount@yahoo.com>, relay=a.mx.mail.yahoo.com[67.195.168.31]:25, delay=1.2, 
delays=0.02/0.06/0.36/0.75, dsn=2.0.0, status=sent (250 ok dirdel)
Mar  2 15:50:33 mydomain postfix/qmgr[68684]: C289314206E: removed
------- End of /var/log/maillog on mail server for Test Message 1 ------------


------ Start of source of message Test 2 as sent from Thunderbird ------------
From - Tue Mar 02 16:06:15 2010
X-Mozilla-Status: 0001
X-Mozilla-Status2: 00800000
Message-ID: <4B8D7D46.8030407@mydomain.com>
Date: Tue, 02 Mar 2010 16:04:06 -0500
From: My Name <myaddress@mydomain.com>
User-Agent: Thunderbird 1.5.0.9 (X11/20061206)
MIME-Version: 1.0
To: Home- A Coworker <heraddress@yahoo.com>
Subject: Test 2
Content-Type: multipart/mixed;
 boundary="------------080409050701090405010702"

This is a multi-part message in MIME format.
--------------080409050701090405010702
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

This is a test message with a 5.8 meg TIFF image file attached to it.

Jim


--------------080409050701090405010702
Content-Type: image/tiff;
 name="CompanyLogo-Blue.tiff"
Content-Transfer-Encoding: base64
Content-Disposition: inline;
 filename="CompanyLogo-Blue.tiff"

SUkqAMjcXAD+/v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+
/v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+
/v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+
<snip>
/v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+/v4RAP4ABAABAAAAAAAAAAABAwABAAAA
QAcAAAEBAwABAAAARQQAAAIBAwADAAAAmt1cAAMBAwABAAAAAQAAAAYBAwABAAAAAgAAAA0B
AgAxAAAAoN1cAA4BAgALAAAA0t1cABEBBAASAAAA3t1cABIBAwABAAAAAQAAABUBAwABAAAA
AwAAABYBAwABAAAAQAAAABcBBAASAAAAJt5cABoBBQABAAAAbt5cABsBBQABAAAAdt5cABwB
AwABAAAAAQAAACgBAwABAAAAAgAAAAAAAAAIAAgACAAvaG9tZS9qaW0vR3JhcGhpY3MvR3Jh
ZmZMb2dvL0dyYWZmTG9nby1CbHVlLnRpZmYAAEdyYWZmIExvZ28AAAgAAAAIcAUACOAKAAhQ
EAAIwBUACDAbAAigIAAIECYACIArAAjwMAAIYDYACNA7AAhAQQAIsEYACCBMAAiQUQAIAFcA
CHBcAABwBQAAcAUAAHAFAABwBQAAcAUAAHAFAABwBQAAcAUAAHAFAABwBQAAcAUAAHAFAABw
BQAAcAUAAHAFAABwBQAAcAUAwGwAAAAAAEsAACAAAAAASwAAIAA=
--------------080409050701090405010702--
------- End of source of message Test 2 as sent from Thunderbird -------------


------ Start of /var/log/maillog on mail server for Test Message 2 -----------
Mar  2 16:04:05 mydomain postfix/smtpd[11420]: connect from unknown[myip]
Mar  2 16:04:07 mydomain postfix/smtpd[11420]: CFEE0142065: client=unknown[myip], sasl_method=PLAIN, sasl_username=myaddress
Mar  2 16:04:08 mydomain postfix/cleanup[18121]: CFEE0142065: message-id=<4B8D7D46.8030407@mydomain.com>
Mar  2 16:04:13 mydomain postfix/smtp[69253]: 35AF0142055: lost connection with f.mx.mail.yahoo.com[98.137.54.237] while sending end of data 
-- message may be sent more than once
Mar  2 16:06:12 mydomain postfix/qmgr[68684]: CFEE0142065: from=<myaddress@mydomain.com>, size=8341480, nrcpt=1 (queue active)
Mar  2 16:06:12 mydomain postfix/smtpd[11420]: disconnect from unknown[myip]
Mar  2 16:06:15 mydomain clamd[5208]: SelfCheck: Database status OK.
Mar  2 16:06:15 mydomain postfix/smtpd[71638]: connect from localhost[127.0.0.1]
Mar  2 16:06:15 mydomain postfix/smtpd[71638]: C737B14206B: client=localhost[127.0.0.1]
Mar  2 16:06:15 mydomain postfix/cleanup[18121]: C737B14206B: message-id=<4B8D7D46.8030407@mydomain.com>
Mar  2 16:06:16 mydomain postfix/qmgr[68684]: C737B14206B: from=<myaddress@mydomain.com>, size=8341924, nrcpt=1 (queue active)
Mar  2 16:06:16 mydomain postfix/smtpd[71638]: disconnect from localhost[127.0.0.1]
Mar  2 16:06:16 mydomain amavis[35823]: (35823-07) Passed CLEAN, [myip] [myip] <myaddress@mydomain.com> -> <heraddress@yahoo.com>, Message-ID: 
<4B8D7D46.8030407@mydomain.com>, mail_id: RHLd+3Tq8Duj, Hits: -, size: 8341480, queued_as: C737B14206B, 4093 ms
Mar  2 16:06:16 mydomain postfix/smtp[63589]: CFEE0142065: to=<heraddress@yahoo.com>, relay=127.0.0.1[127.0.0.1]:10024, delay=129, 
delays=125/0.03/0.01/4.1, dsn=2.0.0, status=sent (250 2.0.0 from MTA([127.0.0.1]:10025): 250 2.0.0 Ok: queued as C737B14206B)
Mar  2 16:06:16 mydomain postfix/qmgr[68684]: CFEE0142065: removed
------- End of /var/log/maillog on mail server for Test Message 2 ------------


------ Immediately after Test Message 2 was sent, my mail queue is -----------
-Queue ID- --Size-- ----Arrival Time---- -Sender/Recipient-------
C737B14206B* 8341924 Tue Mar  2 16:06:15  myaddress@mydomain.com
                                              heraddress@yahoo.com                   
----------------- End of Output ----------------------------------------------


------ A while after Test Message 2 was sent, my mail queue is ---------------
-Queue ID- --Size-- ----Arrival Time---- -Sender/Recipient-------
C737B14206B  8341924 Tue Mar  2 16:06:15  myaddress@mydomain.com
(lost connection with c.mx.mail.yahoo.com[206.190.54.127] while sending end of data -- message may be sent more than once)
                                              heraddress@yahoo.com
----------------- End of Output ----------------------------------------------


------ Start of /var/log/maillog on mail server for an old message -----------
Mar  2 16:07:36 mydomain postfix/smtp[69253]: 35AF0142055: to=<anotheruser@yahoo.com>, relay=g.mx.mail.yahoo.com[98.137.54.238]:25, 
delay=435553, delays=435185/0.06/164/203, dsn=4.4.2, status=deferred (lost connection with g.mx.mail.yahoo.com[98.137.54.238] while sending 
end of data -- message may be sent more than once)
Mar  2 16:07:36 mydomain postfix/qmgr[68684]: 35AF0142055: from=<somebody@anotherdomain.com>, status=expired, returned to sender
Mar  2 16:07:37 mydomain postfix/cleanup[18121]: 058D014206D: message-id=<20100302210737.058D014206D@mydomain.com>
Mar  2 16:07:37 mydomain postfix/bounce[1166]: 35AF0142055: sender non-delivery notification: 058D014206D
Mar  2 16:07:37 mydomain postfix/qmgr[68684]: 058D014206D: from=<>, size=2998, nrcpt=1 (queue active)
Mar  2 16:07:37 mydomain postfix/qmgr[68684]: 35AF0142055: removed
Mar  2 16:07:42 mydomain postfix/smtp[69253]: 058D014206D: to=<somebody@anotherdomain.com>, relay=barracuda.anotherdomain.com[anotherip]:25, 
delay=5.1, delays=0.03/0/3/2, dsn=2.0.0, status=sent (250 Ok: queued as 124BA2A4013)
------- End of /var/log/maillog on mail server for an old message ------------
 
My Mail Server Config

My mail server is running FreeBSD 7.1-RELEASE and I'm using Postfix 2.6.5,1 as my MTA. I have ALTQ enabled so that a there should always be bandwidth available for messages to be sent. All messages are run through amavisd-new/clamd before being accepted for delivery. Everything is pretty standard AFAIK, and I know it works because NO other mail provider that I've encountered over the ~3 years the mail server has been live has had this problem.

Code: 
# postconf -n
body_checks = regexp:/usr/local/etc/postfix/body_checks
broken_sasl_auth_clients = no
command_directory = /usr/local/sbin
config_directory = /usr/local/etc/postfix
content_filter = smtp-amavis:127.0.0.1:10024
daemon_directory = /usr/local/libexec/postfix
data_directory = /var/db/postfix
debug_peer_level = 2
default_destination_concurrency_limit = 10
header_checks = regexp:/usr/local/etc/postfix/header_checks
home_mailbox = Maildir/
html_directory = /usr/local/share/doc/postfix
local_destination_concurrency_limit = 2
mail_owner = postfix
mailq_path = /usr/local/bin/mailq
manpage_directory = /usr/local/man
message_size_limit = 26214400
mime_header_checks = regexp:/usr/local/etc/postfix/mime_header_checks
mydestination = <list of my domains>, localhost
mydomain = <my main domain>.com
mynetworks_style = host
myorigin = $mydomain
newaliases_path = /usr/local/bin/newaliases
queue_directory = /var/spool/postfix
readme_directory = /usr/local/share/doc/postfix
relay_domains = <list of my domains>, 127.0.0.1, localhost
sample_directory = /usr/local/etc/postfix
sendmail_path = /usr/local/sbin/sendmail
setgid_group = maildrop
smtp_tls_cert_file = /usr/local/etc/postfix/cert.pem
smtp_tls_key_file = /usr/local/etc/postfix/key.pem
smtp_tls_note_starttls_offer = yes
smtp_use_tls = yes
smtpd_client_restrictions = check_client_access hash:/usr/local/etc/postfix/client_access, permit
smtpd_delay_reject = yes
smtpd_helo_required = yes
smtpd_helo_restrictions = permit_mynetworks, check_helo_access hash:/usr/local/etc/postfix/helo_access,  reject_invalid_hostname, permit
smtpd_recipient_restrictions = reject_unauth_pipelining,  reject_non_fqdn_recipient,  reject_unknown_recipient_domain,  permit_mynetworks,  
permit_sasl_authenticated,  reject_invalid_hostname,  reject_non_fqdn_hostname,  reject_non_fqdn_sender,  reject_unknown_sender_domain,  
reject_unauth_destination,  reject_rbl_client zen.spamhaus.org,  check_policy_service inet:127.0.0.1:10023, permit
smtpd_sasl_auth_enable = yes
smtpd_sasl_security_options = noanonymous                                       
smtpd_sender_restrictions = permit_mynetworks,  permit_sasl_authenticated,  reject_non_fqdn_sender,  reject_unknown_sender_domain,  permit
smtpd_tls_CAfile = /usr/local/etc/postfix/cacert.pem
smtpd_tls_auth_only = yes
smtpd_tls_cert_file = /usr/local/etc/postfix/cert.pem
smtpd_tls_key_file = /usr/local/etc/postfix/key.pem
smtpd_tls_loglevel = 0
smtpd_tls_received_header = no
smtpd_tls_security_level = may                                                  
smtpd_tls_session_cache_timeout = 3600s
strict_rfc821_envelopes = yes
tls_random_source = dev:/dev/urandom
unknown_client_reject_code = 450
unknown_hostname_reject_code = 554
unknown_local_recipient_reject_code = 550



Yahoo's Standard Response

Yahoo doesn't actually READ my messages, as evidenced by my having received the same form response several times. (Right down to the mis-spelling. ;) ) This is one of them that was in response to my asking if they could look in their logs at the times of the errors in my logs above to see if there's something useful, but it's used for a standard response:

Various Yahoo Postmasters said:
Thank you for writing to Yahoo! Mail.

If you continue to experience this delivery issue, I would appreciate it
if you could provide a full thread that shows an SMTP connection that
resulted in a delivery error. Please provide both (at the very minimum,
at least one) of the following:

* The output of a manual SMTP test (typically with telnet) from your
mail server to our servers (e.g., mx1.mail.yahoo.com) showing the SMTP
conversation leading up to and including the error message.

* Log messages from your mail server showing which IP you connected to
and what responnses you got from the remote server at the time you
received the failures/errors.

Without this information, we are unable to further investigate the
matter.

Note: If you are not the administrator for the mail server(s) affected,
I encourage you to contact the administrator so they can provide this
information needed to effectively troubleshoot the issue.

For assistance with delivery issues to Yahoo! Mail, please visit:

http://postmaster.yahoo.com/

Your patience is greatly appreciated.

Thank you again for contacting Yahoo! Mail. Your case number for this
issue is blahblahblah. Please reference it in all future communication about
this particular issue.

Regards,

<random name>

Yahoo! Mail Customer Care

http://postmaster.yahoo.com
Click to expand...

This is maddening, to say the least. I wrote them an angry response, but haven't yet sent it - going to review/edit it Monday when I'm calmer. Doesn't really matter what I send them because they don't read it anyway. :( So frustrating when I can reproduce the error at will, but they refuse to even look in their mail logs to see if there's a more descriptive error message.



Final Puzzlement/Plea for Advice

I've tried google, but there are few hits on this subject, less in English, and none that I found that were of any help. It's very interesting to me, and probably the key to the puzzle, that it only happens when sending mail from my server to yahoo and not the reverse. I just thought that I could possibly sniff the packets as a message is delivered and throw that at them, though I expect nothing different in response because they don't read the messages anyway. Does anybody have any ideas of what I could do to either troubleshoot more on my side or have a contact at yahoo who might be willing to work with me in isolating & solving the trouble?
 
DutchDaemon said:
http://forums.freebsd.org/showthread.php?t=3890 (try the sysctl)
Click to expand...

Thanks for the link DD. I changed the sysctl from it's default of 3000 on FreeBSD 8 to 100000 and tried again, but the message again bounced when my server tried to deliver it to yahoo.



J65nko said:
Have you tried to capture the traffic with tcpdump and investigate the dump?
Click to expand...

That was going to be my next step. I grabbed a capture file and went through it, but can't see anything abnormal. The file ends, the final ACKs are sent, and that's it. :( Wireshark does see the IMF message and is able to display the entire message as it was sent to yahoo; looks normal as far as I can tell.

End of the capture:
Code: 
0d 0a 2e 0d 0a 51 55 49 54 0d 0a
CR LF .  CR LF Q  U  I  T  CR LF

I forwarded this capture file to yahoo, along with my mail log from today; hopefully I'll get something other than a form response back this time.
 
Try to do disable TCP window scaling.

I am not near a FreeBSD box now, but on OpenBSD this is the following sysctl
Code: 
$ sysctl -a | grep 1323
net.inet.tcp.rfc1323=1
Set it to zero and retry ;)
 
J65nko said:
Try to do disable TCP window scaling.

I am not near a FreeBSD box now, but on OpenBSD this is the following sysctl
Code: 
$ sysctl -a | grep 1323
net.inet.tcp.rfc1323=1
Set it to zero and retry ;)
Click to expand...

It's the same name on FreeBSD, but it was already set to 0 on my box.
 
I got the same problem & reply from stupid yahoo. I ask all my staff to have a gmail account forgetting yahoo.

When I telnet I found this - yahoo servers resets the connection after 10 seconds of each command. That's why tiny text messages gets through. It can travel within 10secs. But with an attachment, stuck in the mail queue.

Still I don't have a solution. Hope yahoo will see this and act.
 
Hi Ruler2112

I am a Windows Admin using Exchange 2k3 and Trend IMSS for mail scanning and I'm also seeing the large email delivery issue as well. I hear your pain about Yahoo support, and how they want me to manually type out an SMTP connection. It is good to hear that I'm not the only one getting that type of "support"

Here are my logs, and I'm getting the same issue you are, but from what I can tell the attachment is fully sent, but the server fails to acknowledge the transfer. In the end I just might forward all @yahoo* emails to my ISP's mail server and let them deal with it.


Code: 
2010/11/17 17:10:40.875	[4328]	31	D	Command: [DATA]	(E05267E7-0E89-4B72-B6A4-5A85A8E6E957,10.1.3.24:55510-
98.137.54.238:25)		[smtpclientchanel.cpp(1546),CSmtpClientChanel::_SendCmd]

2010/11/17 17:10:41.422	[4328]	31	D	Response: [354 go ahead	(E05267E7-0E89-4B72-B6A4-5A85A8E6E957,10.1.3.24:55510-
98.137.54.238:25)		[smtpclientchanel.cpp(1572),CSmtpClientChanel::_SendCmd]

2010/11/17 17:10:41.438	[4328]	3F	D	Timing data for task [Send command and receive response for DATA]: 547 ms.	
(E05267E7-0E89-4B72-B6A4-5A85A8E6E957,10.1.3.24:55510-98.137.54.238:25)		[smtpclientchanel.cpp(1550),CSmtpClientChanel::_SendCmd]

2010/11/17 17:10:41.438	[4328]	31	I	Begin to transfer message data after DATA command.	(E05267E7-0E89-4B72-B6A4-
5A85A8E6E957,10.1.3.24:55510-98.137.54.238:25)		[smtpclientchanel.cpp(1354),CSmtpClientChanel::_DoSendMail]

2010/11/17 17:10:41.453	[4328]	31	I	Message size is 7130939 Bytes (6963 KB or 6 MB).	(E05267E7-0E89-4B72-B6A4-
5A85A8E6E957,10.1.3.24:55510-98.137.54.238:25)		[smtpclientchanel.cpp(1629),CSmtpClientChanel::_SendFile]

2010/11/17 17:10:41.453	[4328]	31	D	Before deliver: Remove headers X-TM-IMSS-BATV-Tag-Sender;X-TM-IMSS-BATV-Data;X-TM-IMSS-
BATV-Failed-Rcpts;X-TM-IMSS-Mail-Type.	(E05267E7-0E89-4B72-B6A4-5A85A8E6E957,10.1.3.24:55510-98.137.54.238:25)		
[smtpclientchanel.cpp(1644),CSmtpClientChanel::_SendFile]

2010/11/17 17:10:41.469	[4328]	31	I	Use default buffer,size = [2048]	(E05267E7-0E89-4B72-B6A4-
5A85A8E6E957,10.1.3.24:55510-98.137.54.238:25)		[smtpclientchanel.cpp(1702),CSmtpClientChanel::_SendFile]

2010/11/17 17:14:21.892	[4328]	31	E	Failed to get response,the connection via socket 0x4ec is gracefully closed by remote 
peer.	(E05267E7-0E89-4B72-B6A4-5A85A8E6E957,10.1.3.24:55510-98.137.54.238:25)		
[smtpclientchanel.cpp(1523),CSmtpClientChanel::_GetResp]
 
Well im just having this exact same issue.... Linux Postfix, MSexchange, you name it fails to send emails with 3MB or more attachements to yahoo... the only thing that i could do is to temporarily route emails to yahoo using a different ISP and it work. Contacted my ISP netadmin and they could not reproduce the issue on their network, Contacting yahoo is not helping. Did you manage to fix the problem?
 
Nope - never did figure it out - without the cooperation of yahoo to troubleshoot, there's not much possible that I can see to try. :( I'm unable to fathom how yahoo can be such a large e-mail provider and have a flaw in their stuff that makes a problem like this occur. (I say they have a flaw because there's no issues sending anywhere else.) Their support department is the worst I've ever dealt with, which is really saying something because I've interacted with some really dumb/apathetic/lazy/stupid/uncaring/etc companies in the past... yahoo mail seems to embody all of these traits. :(

How does one redirect only messages intended for yahoo users to another mail server for relay? I'm familiar setting up a forward to another mail server, but was not aware you could do it only for messages to a specific domain.
 
Are you all who have problems with Yahoo on a PPPoE connection to the internet (or some other type of connection that restricts maximum MTU from the default 1500)? Problems like this could be related to faulty PTMU discovery because Yahoo has possibly blocked certain types of ICMP messages and the PMTU discovery fails to notice that the incoming connection has reduced MTU.

http://en.wikipedia.org/wiki/Path_MTU_Discovery
 
Yahoo mail server woes

I too am having problems sending to yahoo mail servers. I'm using 'Sun Java Messaging Server 7' on Solaris 10, but I think this error will apply to any OS, any MTA server.

It's not just @yahoo.com addresses I get this error, but mostly it is them. Basically their mail infrastructure sucks and they can't cope with the volume of traffic they try to provide. In most other industries, they would not get away with these sort of practices.

Assuming that it is PMTUD not playing well with yahoos mail servers / firewalls. I turned off PMTUD and set MTU to 1440 and MSS to 1400. Then lowering again; set MTU to 1400 and MSS to 1360. I tested using the following script:

Code: 
#!/bin/bash

sender=someone@somedomain.com
recipient=someonelse@anotherdomain.com
mailserver=mail.anotherdomain.com

{ 
    sleep 3; 
    echo 'ehlo';
    sleep 3;
    echo "MAIL FROM:<${sender}>";
    sleep 3; 
    echo "RCPT TO: <${recipient}>";
    sleep 3;
    echo 'DATA';
    sleep 3;
    echo -e "To:${recipient}\nMIME-Version: 1.0 (mime-construct 1.9)\nContent-Type: application/zip\nContent-Transfer-Encoding: base64\n\n";
    dd if=/dev/urandom bs=4 count=400000 2>/dev/null | openssl base64;
    echo '.';
    echo '';
    echo 'quit';
} | telnet ${mailserver} 25

which will send a random 2MB attachment email.

It failed from the zone with mail server on it, and from the global zone. Firewall turned off, it's direct out on WAN to a fibre optical ethernet connection from a reputable ISP.

I then tried it on my new FreeBSD 8.2 CUPS printing/test server, seperate hardware; same thing, can't send attachments over ~100KB. So that rules out my ISP and fibre optic modem, and the mail server itself.

Then I tested it on my Solaris 10 server at home on exactly the same kernel version "Generic_142901-03 i86pc i386 i86pc"; It seemed to work OK on a 4MB attachment, but not on a 8MB attachment.

Generally, I get the impression Yahoo is dropping connections and emails without a proper delivery failed notification.
 
Done some more tests. It's confusing because the way yahoo deal with mail after successful SMTP delivery is not predictable, in-fact it appears inconsistent. I think the behavior is categorized by the size of email.

It looks like it's the connection our ISP provides us that is causing the problem (aside from yahoo mail servers). Whether it's the fibre-optic modem or their network I can't say at this stage, but it's definitely not my server or any other kit at my end. We use a highly reputable ISP and it's a deicated ethernet line (not cheap). And yet at my folks house in UK
(the other side of the world to me now) I have a domestic ADSL connection with 2 static IPs. No problems sending mail to yahoo from there. :P
 
Hello, just to give an update from my side. In the end apparently it WAS an ISP issue... I was routing emails to Yahoo using another ISP and it was working fine but not from our primary. I contacted them about the situation; at first they blamed Yahoo, but apparently another costumer reported the same issue. But there's a mix of things that happened in my situation since we were also scheduled to receive a bandwidth upgrade. As soon as they notified us about the upgrade being completed I rerouted the messages to Yahoo back to the main ISP and the issue disappeared. The only change that happened. They never told me if they did something specifically for Yahoo.

I learned that my ISP uses something like a packet shaper or something like that and I'm thinking that when they upgraded our bandwidth they reset a rule or something. It's a weird problem to have, in the end I reported everything to my boss and gave up until the bandwith upgrade.
 
I really question if it is the connection, as Yahoo addresses are the ONLY ones that have problems. I have business grade ADSL lines - one at 3 meg and one at 6 meg, the latter of which is the fastest available here. I swapped lines on my mail server late one evening and found that the same problem happens on each.

The thought of a traffic shaper causing the problem is interesting, enough so that I called my ISP and asked them about it. They reported that there is no traffic shaping or filtering present on the lines and both are just raw connections to the Internet.


Crash - How fast was/is your connection and how big of a file did you try sending in both conditions? I wonder if Yahoo waits for a set period of time and if the message isn't done by then, assumes it's timed out and junks it. It would explain why increasing your speed fixed the problem if the same size message was sent.


Connection speed really shouldn't matter though - if I'm not mistaken, standards-compliant mail servers should accept a message even if it were sent via an extremely slow connection as long as it's not interrupted. Then again, most major mail providers have help more competent than the squirrels in my backyard... ;)
 
My main connection was 15 Mbps and we upgraded to 20 Mbps and the backup connection is wireless ISP and 5 Mbps of bandwidth, So it's definitely not a bandwidth issue because it works with only 5Mbps and not with 15mbps. I mostly tested with an 8MB mp3 file but I also generated a 5MB text file and same problem attached or in the email body. Why only yahoo is a mystery...
 
Another U-turn in my diagnosis

Well, after some more tests, I've finally cracked it my end. I just put my old domestic linksys router as my WAN switch et viola. That made me curse HP for a dud or non-compliant ProCurve 1400-8G... Until I tried an old and trusted 10/100Mbps 24 port switch which behaved differently again.

HP ProCurve 1400-8G (considered best in class by most experts) => will not send, error writing data.

Old 24 port switch (good parts though to last 10+ years and going strong) => sends ~4MB attachment in 5/6 mins (consistently).

2 year old Linksys SD2008 (8 port 10/100/1000) => sends ~4MB attachment in ~30 seconds (consistently).

So, the cheapest router fairs the best and the industrial grade HP is turned into a brick, thanks to yahoo mail.

Irony is; I replaced the Linksys about 8 months ago with a better HP router because the Linksys would overheat on the weekend and I would have to come to work to turn it off for 5 minutes. That's about when my troubles with Yahoo began, but how could I have known?!

It's definitely an obscure packet level quirk because of some crazy Yahoo measure (probably firewall / packet sniffer). Or perhaps they're using some kind of link aggregation that our switchgear/NICs don't play well with.

I recommend you to do low level tests through a process of elimination, changing all factors between your server and the internet.

As much as I love FreeBSD, I wouldn't have solved this for myself without Solaris. The telnet command reports "Error writing data", but in FreeBSD, no such feedback. That "Error writing data" corresponds directly to the mail servers' "Error writing SMTP data".

Good luck guys, track it down and change what you need to (if you can), because we ain't got a hope in H3ll of Yahoo getting their act together.
 
I had some issues regarding Yahoo deliveries. It just didn't go. Since we're an ISP doing significant mail volumes without problem, I put blame on stupid Yahoo. Needless to say, those packets travel via enterprise level hardware inside our network, and I'm not going to tweak and fiddle around a mail server that's running thousands of mailboxes successfully because of some Yahoo's idiotic network policy.

Friend says that a lot of board admins around the world complain of Yahoo not delivering activation mails.

And a bit of-topic;

I replaced the Linksys about 8 months ago with a better HP router because the Linksys would overheat on the weekend and I would have to come to work to turn it off for 5 minutes
Click to expand...

What series? Here's my home WRT54GL;

Code: 
root@gate:~# uptime
 02:50:33 up 149 days,  9:22, load average: 0.00, 0.00, 0.00
 
Good job on fixing the problem at your site ethoms! Interesting that a switch would cause such a problem.

Unfortunately, I have nothing between my mail server and the internet. It's obviously not a problem between the client and my mail server because the mail is stuck in the queue for 5 days and delivery is tried by my server every hour. I already tried swapping my DSL modem with another at the beginning of this whole mess, so that's not it. I guess I could try replacing the NIC in the box, but I honestly don't think it'll have any effect because no other mail destinations are affected. At this point, I really don't think I'm going to mess with blindly replacing hardware in a server in the hope that something will conform to whatever #$%@ed up form yahoo wants...

How I wish somebody semi-competent at yahoo (if they have such a person) would look at this - gotta be something weird in their networking that is the source of the problem.
 
You must log in or register to reply here.
Back
Top