function readOnly(count){ }
Starting November 20, the site will be set to read-only. On December 4, 2023,
forum discussions will move to the Trailblazer Community.
+ Start a Discussion
ChadMeyerChadMeyer 

554 Domain contains illegal character (apex email service)

We have a custom email to case solution setup using Apex Email Services and have been seeing the following error once a week sent to the address specified for error routing:

 

+++++++++++

The attached message was sent to the Email Service address <e2c@xxxxxxxxxxx.in.salesforce.com> but could not be processed because the following error occurred:

 

554 Domain contains illegal character

+++++++++++

 

According to Salesforce.com support, the issue lies in the Apex Class specified in the email service.  I find this difficult to understand as the error makes no mention of either the class name or the namespace it originates from.  A careful examination of failed emails revealed no apparent RFC issues with the domain names in any of the email fields.  My understanding is that the Apex Email Service parses the email fields out (Subject, Text Body, From, To, etc.) and the Apex Class references that.

 

I would appreciate any thoughts on this.

paul-lmipaul-lmi

could you post the headers from the original message that's failing?  Based just on your description, I think you were given incorrect info.  yes the class does parse it, but the error message itself would seem to indicate that the message was never given the chance to hit your class.

 

We get these too, and the short and skinny is, if the incoming email is malformed or otherwise not compliant with email RFC's for formatting specific parts, the SF email handler will just bounce it and throw you the error rather than even attempting to pass it to your code.

 

There's this one company that keeps auto-emailing one of our email services, and their outbound email server/sender has no from address, and SF bounces that too.

ChadMeyerChadMeyer

Here is the headers with some data hidden due to privacy issues.  I appreciate your throughts on this!

headers

paul-lmipaul-lmi

I was hoping I'd see something that'd jump out at me, but didn't.  Realistically, unless it's an unhandled exception in your apex code, it's completely out of your control (unless it's an email server config issue on the sender side, and you control that).

ChadMeyerChadMeyer

In most cases emails come directly from the sender to the salesforce.com routing address without the typical forwarding in the middle.  Eitherway, I agree, the sending server is our problem, not SFDC's.  The fact that the same sender can send several emails in the same day and have just one be bounced makes me think the problem isn't with the sending server(s).

 

In terms of an unhandled exception, I wouldn't expect to see "554 Domain contains illegal character" in that case, right?  That error must come from somewhere, and if isn't in our class, it must come from the underlying Apex Email Service "system".  Do you agree?

paul-lmipaul-lmi

Totally agree.  I'd actually recommend opening a case with them, and attach the email that "breaks" their system.  Since you have no control over the contents of the email before it hits your class, this is more of a bug/feature request than something you can code around.

RStevensRStevens

Chad,

We've seen a number of these and so far we believe they are all related to addresses that look like the this one your email:

 

To: "blah@demandtec.com" <'blah@demandtec.com'>

 

The problem is the single quotes inside of the bracketed address.  I think that is a legal character for the local part, but definitely not for the domain part of the address.  Apparently our MTA tolerates these, but our application code (based on Javamail) does not.    So, this has nothing to do with your Salesforce generated inbound email address or Apex code per se.

 

Althought technically it's not a bug in Salesforce, we've seen a lot of these and will treat it as such.

 

Rick

JoanaJoana

Hi,

 

I'm having the same error described above. Did anyone find a solution for this problem?

Thank you!

ic2kchad2ic2kchad2

Unfortunately not, we are just tolerating it for now.