Skip to main content

Error "<#5.5.2 smtp;554 5.5.2 Invalid data in message> #SMTP#" when you send attachment in your mail

Some users were receiving error <#5.5.2 smtp;554 5.5.2 Invalid data in message> #SMTP# when they sent message with attachment.

The problem is when attached document name is longer than 50 characters. Some Firewalls have header size restriction and that limit blocks this messages to be sent.

To correct this, change header limit on affected Firewall or shorten the name of the document you are sending (which is probably not good permanent solution).

******
Update #1: Default header size limit in Exchange 2007 is 64K.

Update #2: It might be the SMTP version problem. Mail is rejected with CONTENT-DISPOSITION error (overly long message header field for CONTENT-DISPOSITION) but not for all SMTP servers (same mail sent through different SMTP servers). If you send mail with attachment that has name longer than 50 characters from Exchange 2007 directly through DNS you may encounter this error, but if you send same mail from Exchange 2007 through smart host (other than Exchange) mail is delivered with no errors (possible workaround).

Update #3: There is a good article on Symantec's web site about parameters in Config.cf file. Check SMTP block/unblock possibilities.
Article:
http://service1.symantec.com/SUPPORT/ent-gate.nsf/pfdocs/2002031311321154?OpenDocument&ExpandSection=13%2C8

Update #4: Anonymous (*send me your name*) left a comment below regarding reasons for this error message:
"We found this was simply a matter that the message was created in Outlook "rich text" format (which embeds attachments into the message body) instead of plain text or HTML which creates attachments normally"

Labels:

Comments

  1. AnonymousJune 28, 2007 at 3:12 PM

    Thanks a lot! We were having this problem for some time and finally here's the answer.

    ReplyDelete
  2. AnonymousAugust 24, 2007 at 10:13 PM

    Thanks! Solved it for me too :o)

    ReplyDelete
  3. AnonymousDecember 6, 2007 at 9:40 AM

    It will solve the problem for us if we can know how to change the header limit in Symantec Gateway Firewall 5620.

    Any Help?

    ReplyDelete
  4. AnonymousDecember 10, 2007 at 10:34 PM

    Hi & thanx a lot. We are experiencing the same problem with a Symantec 1620 Gateway Security appliance. By any chance is there any update info available on this topic? Or any other workaround? Problem is, that since a few days even some inbound mail is dropped and it looks like exactly the same error.

    Stefan

    ReplyDelete
  5. DuĊĦan SoraviaDecember 10, 2007 at 11:25 PM

    Hi guys,
    There is a good article on Symantec's web site about parameters in Config.cf file. Check SMTP block/unblock possibilities. :)

    Article:
    http://service1.symantec.com/SUPPORT/ent-gate.nsf/pfdocs/2002031311321154?OpenDocument&ExpandSection=13%2C8

    ReplyDelete
  6. AnonymousJanuary 17, 2008 at 4:26 PM

    We found this was simply a matter that the message was created in Outlook "rich text" format (which embeds attachments into the message body) instead of plain text or HTML which creates attachments normally.

    ReplyDelete
  7. AnonymousFebruary 11, 2008 at 8:32 AM

    Here is the solution for SGS 5620 und SGS 1620.

    In the sgs console at "Administration" Advanced Options set this entries.

    smtpd.max_body_line_length (value: 2048)
    smtpd.scan_message_body (value:False)

    save Configuration and activate it, for me it works :-)

    Markus

    ReplyDelete
  8. DuĊĦan SoraviaFebruary 11, 2008 at 8:52 AM

    Thanks Markus for taking time to write this!

    ReplyDelete
  9. AnonymousJuly 16, 2008 at 10:50 AM

    Thanks Markus, for me it works too !!

    Bernd

    ReplyDelete
  10. AnonymousJanuary 12, 2009 at 9:40 PM

    Thank you Markus! Worked great!
    Steve

    ReplyDelete
  11. AnonymousJuly 15, 2009 at 5:33 PM

    Markus,

    Thanks so much! I followed what you said and worked great! were getting the emails now.

    Ron

    ReplyDelete
  12. AnonymousNovember 18, 2013 at 10:21 PM

    This just recently started happening to my 2003 Exchange server and seems a bit inconsistent. On just about any email sent from phones connected via activesync that contains images it will bounce them. Attach a PDF and your ok. Where can we set the header limit in Exchange 2003 since my Firewall has not changed and could care less on anything outbound anyway?

    ReplyDelete

Post a Comment

Popular posts from this blog

Reason: [{LED=250 2.1.5 RESOLVER.GRP.Expanded; distribution list expanded};{MSG=};{FQDN=};{IP=};{LRT=}]

 If you got this error checking the mail flow for a distribution group, it means the distribution group is closed and only internal senders can send e-mail to this group. When outside user sends e-mail to this group you get  Reason: [{LED=250 2.1.5 RESOLVER.GRP.Expanded; distribution list expanded};{MSG=};{FQDN=};{IP=};{LRT=}] Set Delivery for this group to internal and external users and your problem will be solved. 
Read more

Netscaler vs Exchange 2019 "time out during ssl handshake stage

If you are using Citrix Netscaler as load balancer in front of Exchange 2019 server you must know this: Microsoft Exchange 2019 is secured by default and allows only TLS 1.2. Therefore default schannel settings are as follows (using IISCrypto tool from Nartac Software): While Citrix Netscaler offers following Cipher Suites: TLS_RSA_WITH_AES_256_CBC_SHA TLS_RSA_WITH_AES_128_CBC_SHA TLS_DHE_RSA_WITH_AES_256_CBC_SHA TLS_DHE_RSA_WITH_AES_128_CBC_SHA TLS_DHE_DSS_WITH_AES_256_CBC_SHA TLS_DHE_DSS_WITH_AES_128_CBC_SHA TLS_RSA_WITH_DES_CBC_SHA TLS_RSA_EXPORT_WITH_DES40_CBC_SHA TLS_RSA_EXPORT_WITH_RC2_CBC_40_MD5 TLS_DHE_DSS_WITH_DES_CBC_SHA TLS_DHE_DSS_EXPORT1024_WITH_DES_CBC_SHA TLS_DHE_DSS_EXPORT_WITH_DES40_CBC_SHA TLS_DHE_RSA_WITH_DES_CBC_SHA TLS_DHE_RSA_EXPORT_WITH_DES40_CBC_SHA TLS_RSA_EXPORT1024_WITH_RC2_CBC_56_MD5 TLS_DH_anon_WITH_DES_CBC_SHA TLS_DH_anon_WITH_AES_128_CBC_SHA TLS_DH_anon_WITH_AES_256_CBC_SHA TLS_DH_anon_EXPORT_WITH_DES40_CBC_SHA Now, you will fi...
1 comment
Read more

Ports that need to be open on Firewall for Edge Transport servers

Ports that need to be open on firewall for Edge Server subscription with Hub Server to function properly: For Inbound traffic: SMTP - TCP port 25 (from Internet) SMTP - TCP port 25 (from Edge server to Hub server on internal network) For Outbound traffic: SMTP - TCP/UDP port 25 (from Edge to Internet) SMTP - TCP/UDP port 25 (from Hub to Edge server) LDAP for EdgeSync - TCP port 50389 (from Hub to Edge server) Secure LDAP for EdgeSync - TCP port 50636 (from Hub to Edge server) Since Edge server needs to communicate with Hub server it is important that it can resolve Hub transport servers by FQDN and Hub transport servers must be able to resolve Edge servers by its FQDNs. To accomplish this you need to either open 53 (DNS) port and configure internal network adapter to use internal DNS but as a security precaution I would suggest to enter DNS records for Edge servers on local DNS manually and to fill hosts file on Edge servers with FQDNs for Hub transport servers.
2 comments
Read more