locked
Marked as spam problems with outgoing e-mail through E-mail router RRS feed

  • Question

  • Hello,

    We have CRM 4.0 set-up with e-mail integration through E-mail router and we encounter the following problem:

    When a CRM user set for "E-mail access type - Outgoing" to "E-mail router" tries to send an e-mail to an external e-mail address (a contact), the message is undelivered due to spam reasons (SpamAssasin), and the following NDR is received in the sender's Inbox:

    Your message did not reach some or all of the intended recipients.

     

          Subject:    check 1649 CRM:0020013

          Sent: 31.08.2009 16:51

     

    The following recipient(s) cannot be reached:

     

          recipient@anydomain on 31.08.2009 16:51

                Nu aveţi permisiunea de a trimite un mesaj la acest destinatar. Luaţi legătura cu administratorul reţelei.

                <gecad09.gecadco.local #5.7.1 smtp;554 5.7.1 Rejecting because message seems to be SPAM. This could be because of spam content or structure, links to spam sites, blacklisted mail server or blacklisted client IP. SA Score: 7.743 (BAD_ENC_HEADER,HTML_MESSAGE,HTML_MIME_NO_HTML_TAG,JR_RCVD_HOST_PROBS1,JR_RCVD_HOST_PROBS2,JR_RCVD_TOO_FEW_HOPS,MIME_HTML_ONLY,RDNS_NONE)>


    I suspect that this happens because CRM does not format the message properly, and although we could set up an exception for the messages sent by our CRM, we still might get filtered by the recipient filtering policies.

    Can this be fixed?

    Thank you.

    configuration:
    Windows Server 2008 SP2
    CRM 4.0 (4.0.7333.3)

    Monday, August 31, 2009 2:03 PM

Answers

  • Not sure if you have the tracking token turned on or not but just as a test,  you could temporarily turn it off and try sending another e-mail.  Another option that might help is to load the CRM for Outlook client and send your e-mails through Outlook. 

    I have not heard of this issue in the past so I am not aware that it is a header issue at least in the U.S.
    Best Regards, Donna
    • Marked as answer by Jim Glass Jr Tuesday, September 8, 2009 5:24 PM
    Wednesday, September 2, 2009 11:51 AM
  • We are in the same situation where it seems that increasing numbers of emails sent from CRM are getting filtered.  I can confirm the Spamassassin has the biggest problem with the "BAD_ENC_HEADER" flag.  This flag accounts for half the set spam value on the email server.  Our problem is that we cannot remove the tracking token as we receive/send emails with the same subject and our CRM cases would get rather confusing.

    Researching BAD_ENC_HEADER I find the cause is whitespace in the encoded section(s).  This is in violation of RFC2047.

    In a test email sent from CRM the email title is specified in the headers as follows:

    Subject: =?us-ascii?Q?test CRM:00100513?=

    The space between the title and the token is not allowed according to the RFC.

    Could a solution be to either have CRM restrict the encoding to specifically the token or else properly encode the entire title.
    Wednesday, October 7, 2009 3:14 PM

All replies

  • While it is entirely possible that your content flagged the email it is not so clear that you didn't get stopped for one of the other reasons listed.  It is possible that your users have gotten you blacklisted.  It is also possible that the velocity of emails originating from your SMTP server is popping red flags.  If you have much volume going through in bulk you may need more sophisticated email service provider features that are not included with the straight-through router.  At minimum you should have someone attending to these responses and contacting the challengers to keep your server off the lists.

    Of course, if you are in the business of spamming then things appear to be working properly.

    Monday, August 31, 2009 6:23 PM
  • Thanks for your reply.
    The SMTP that blocks the messages is administered by us and velocity of e-mails and content are not the problem here, as we are just deploying CRM right now. We only sent a couple of test messages,  and we didn't use sensible words like "test" in the subject/body, we made them look like normal production e-mails.

    I will enforce that we are not listed in blocklists, we only get filtered by *our* internal filter and the reasons seem to be related to the message format that CRM uses:

    BAD_ENC_HEADER,HTML_MESSAGE,HTML_MIME_NO_HTML_TAG,JR_RCVD_HOST_PROBS1,JR_RCVD_HOST_PROBS2,JR_RCVD_TOO_FEW_HOPS,MIME_HTML_ONLY,RDNS_NONE

    LATER EDIT: our SpamAssasing admin says that the highest scoring is caused by: BAD_ENC_HEADER (3.5) and HTML_MIME_NO_HTML_TAG (1.66) tests.
    Tuesday, September 1, 2009 7:17 AM
  • Not sure if you have the tracking token turned on or not but just as a test,  you could temporarily turn it off and try sending another e-mail.  Another option that might help is to load the CRM for Outlook client and send your e-mails through Outlook. 

    I have not heard of this issue in the past so I am not aware that it is a header issue at least in the U.S.
    Best Regards, Donna
    • Marked as answer by Jim Glass Jr Tuesday, September 8, 2009 5:24 PM
    Wednesday, September 2, 2009 11:51 AM
  • We are in the same situation where it seems that increasing numbers of emails sent from CRM are getting filtered.  I can confirm the Spamassassin has the biggest problem with the "BAD_ENC_HEADER" flag.  This flag accounts for half the set spam value on the email server.  Our problem is that we cannot remove the tracking token as we receive/send emails with the same subject and our CRM cases would get rather confusing.

    Researching BAD_ENC_HEADER I find the cause is whitespace in the encoded section(s).  This is in violation of RFC2047.

    In a test email sent from CRM the email title is specified in the headers as follows:

    Subject: =?us-ascii?Q?test CRM:00100513?=

    The space between the title and the token is not allowed according to the RFC.

    Could a solution be to either have CRM restrict the encoding to specifically the token or else properly encode the entire title.
    Wednesday, October 7, 2009 3:14 PM
  • Thank you Donna, I guess I can accept disabling the tracking token as a workaround, but I also think the tracking token should be functional without e-mails being marked as spam, by correcting the subject according to RFC (thank you EarthwormSVX).

    Tuesday, November 24, 2009 8:20 PM