Cannot Send Attachments via SMTP

Guys,

I’m having problems sending emails with attachments via SMTP. I’ve tried sending small and huge files (size-wise of course) as attachments and it doesn’t matter. I can send emails without attachments via SMTP, and I can send emails with or without attachments using the Notes protocol (NRCP). I’ve set the maximum message size (in my SMTP/MTA server configuration settings, router/smtp tab, restrictions and controls tab) to 10MB so I think file size is not the problem.

What else may cause the emails not to be sent? Oh and I am not getting any error messages, the mails just get stuck in the mail.box database of my SMTP server. HELP!!!

Thanks a lot!

Subject: Cannot Send Attachments via SMTP

We had this issue last week, but it was because of Norton’s corporate antivirus. Every email sent with an attachment turned up as dead mail in the mail.box. We restarted the Norton services on the domino box and all was well.

Subject: RE: Cannot Send Attachments via SMTP

Thanks Greg, although recent developments have eliminated the possibility of the problem having anything to do with the attachments. The scenarios are so varied that it’d be easier if I just laid them out on a list, so here goes:

  • I am able to send mails with or without attachments, regardless of message size to a FEW selected domains. Interestingly enough, these domains to which I can send large files to all use Microsoft Exchange.

  • I am able to send mails with relatively small message sizes (say less than 3KB) to all internet domains I’ve tried. This includes emails with attachments, given that the total message size is around 3KB.

  • However, if the message size is large (say larger than 4KB), it won’t send REGARDLESS of whether it has or does not have an attachment.

I’m just saying that it somehow has something to do with the message size, it seems.

Honestly, this has got me stumped.

Any kind-hearted SMTP gurus out there?

Thanks again!

Subject: RE: Cannot Send Attachments via SMTP

Sounds like your MIME conversion settings are messed up on your server.

Thinking out loud here, there are a couple things that stick out in my mind that might be causing this.

  1. Since all SMTP mail gets converted to MIME, the settings to convert might have been played with, which would result in the symptoms you’re seeing.

  2. The end user may be sending mail as Rich Text instead of MIME.

Those are the only two things I can think of that might cause what you’re seeing. Of course if you have any 3rd party scanning tools in between, I’d take a close look at those too.

Greg

Subject: RE: Cannot Send Attachments via SMTP

Hey thanks again man. It may be the MIME conversion that’s causing the problem here, but anyway I’ve enabled SMTPClientDebug and now at least I’m getting specific errors.

SMTPClient: Attempting to Connect: Host zzz.xxx.CO.JP, Port 25, SSL Port 0, Connecting Domain aaa.bbb.com.qa

SMTPClient: Connection successful

SMTPClient: ReceiveResponse: 220 zzz.xxx.co.jp ESMTP Sendmail 8.13.1/8.13.1; Wed, 16 Feb 2005 16:24:24 +0900 (JST)

SMTPClient: CommandEHLO: EHLO aaa.bbb.com.qa

SMTPClient: ReceiveResponse: 250-zzz.xxx.co.jp Hello aaa.bbb.com.qa [xxx.yyy.zzz.aaa], pleased to meet you

SMTPClient: ReceiveResponse: 250-ENHANCEDSTATUSCODES

SMTPClient: ReceiveResponse: 250-PIPELINING

SMTPClient: ReceiveResponse: 250-8BITMIME

SMTPClient: ReceiveResponse: 250-SIZE

SMTPClient: ReceiveResponse: 250-ETRN

SMTPClient: ReceiveResponse: 250-DELIVERBY

SMTPClient: ReceiveResponse: 250 HELP

SMTPClient: Attempting to SubmitMessage:

SMTPClient: Pipelined commands:

SMTPClient: MAIL FROM:admin@bbb.com.qa SIZE=826

SMTPClient: RCPT TO:some.one@xxx.co.jp

SMTPClient: DATA

SMTPClient: End of pipelined commands

SMTPClient: ReceiveResponse: 250 2.1.0 admin@bbb.com.qa… Sender ok

SMTPClient: ReceiveResponse: 250 2.1.5 some.one@xxx.co.jp… Recipient ok

SMTPClient: ReceiveResponse: 354 Enter mail, end with “.” on a line by itself

SMTPClient: Data Send Succeeded 1880 bytes

SMTPClient: Connection broken after an error sending DATA command

SMTPClient: Attempting to Disconnect:

SMTPClient: Connection already disconnected

Router: No messages transferred to xxx.CO.JP (host zzz.xxx.CO.JP) via SMTP

The error it seems is:

SMTPClient: Connection broken after an error sending DATA command

It looks like the connecting client (my server)

is having problems sending the DATA command.

Anyone had this same trouble before? I know the error now, but I still have no clue how to fix it… SOMEONE HEEELP!!!

Thanks!

Subject: RE: Cannot Send Attachments via SMTP

Is it possible that the SMTPClient (sender)is taking a long time to send the DATA that the receiver simply drops the connection?

Isn’t there a notes.ini parameter that I can change to lengthen the time the server will wait for the DATA command to finish?

TIA!

Subject: RE: Cannot Send Attachments via SMTP

Could be caused by packet fragmentation?

Try MTU size.

http://chris-linfoot.net/d6plinks/CWLT-5WADL5

That article is about email reception, but the MTU size issue can also cause problems with sending.

Subject: RE: Cannot Send Attachments via SMTP

Thanks Chris.Err… how does one alter the MTU size on the Domino server?

Subject: RE: Cannot Send Attachments via SMTP

whoa!!! MTU was the culprit!!!

This problem can be a big pain in the butt, so

for future reference:

  1. Open Registry Editor.

  2. Under the key:

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters\Interfaces[ID for Adapter]

  1. Add a new DWORD value, name it MTU and set it’s value to 1400 (this is in decimal).

I set it to 1400 because I read somewhere when I was googling for info that 1400 seems a good round number to fix this kind of problem. I also read that the default value for MTU is around 1500, and setting it to a lower value would make all the bad things go away. :smiley:

Anyway don’t forget to first backup your registry before messing around with it.

Some useful links:

http://support.microsoft.com/default.aspx?scid=kb;en-us;120642

http://chris-linfoot.net/d6plinks/CWLT-5WADL5

Again, thanks Chris and Greg. Owe you guys big time!