CDOSYS itself is generating a SPAM error!

antic

antic

Perch
This just started happening a couple of days ago.

When an application of mine executes the cdosys .Send method to send an email, it returns with the following error:
Code: 
(Error code -2147220975)
The message could not be sent to the SMTP server.
The transport error code was 0x800ccc6f. 
The server response was 554 Sorry, this message appears to be spam (#5.6.0)
It sounds like the mail server itself (mail3) is refusing to relay this email from CDOSYS, saying it's SPAM, even though it's coming from within the network - i.e. from the web server.

Why is this happening and what can be done about it? This false-positive spam issue is becoming ridiculous! A client's e-commerce app is simply trying to send a purchase receipt and failing because of this error. It's not part of a bulk-mailout or anything like that. What is the purpose of this?
 
Apparently a recent HSphere update changed a few things and affected some antispam settings. Many thanks to Stephen & co. for sorting this strange problem out extremely quickly for me!
 
I am having the same issue and have openned a ticket about it --- this is a critical issue for me to get resolved.

It was erroring earlier, then worked fine for a bit, and is now erroring again.

... of course this is happening at the worst possible time
 
Of course. :)

Yeah it's started up again here too. Just opening a ticket now. I think the main spam "condition" that is sending it over the 7.0 score is this one:

3.3 FH_MSGID_01C67 Special MSGID

The problem is, CDOSYS is generating the message ID, which SpamAssassin is then complaining about - which is crazy. That MSGID condition should be removed.
 
...so I tried disabling the spam filter on the sending account I was using for the SMTP authentication and the error has disappeared... could it be that simple of a fix, however it is quite annoying - any text body was causing the error, html body would not

arghhhh
 
Did you just need to disable spam checking for the sender? That is, for the "FROM" address?
 
The from address in the script and the account I used for SMTP authentication in the script for on Mail3 are the same -- I just edited that account and disabled spam filtering
 
now that I think about this, this could be related to my issue of not being able to send email to a hotmail account no way earlier without being bounced as spam...

I noticed that DSPAM seemed to have forgotten all that its learned earlier and marked stuff as spam too that it didn't before --- I really had to turn down my spam filtering to get my messages again.

Oh, in case nobody has noticed.... I HATE SPAM AND ALL THE F'N ISSUES THAT ARISE AROUND IT.

...gawd, I need sleep.
 
Thanks for the tip George, I've removed antispam from the email account I use to authenticate on. Hopefully that will stop this problem.

Cheers!
 
Excellent - thank you.

In my ticket on this I did provide my complete script if support wants to try and duplicate the error.
 
It's just happened again for me. :(

I had completely removed spam checking for the authentication email account, and changed overall spam setting to "relaxed".

But my app is still raising this error when sending the email via CDOSYS.

-2147220975: The message could not be sent to the SMTP server. The transport error code was 0x800ccc6f. The server response was 554 Sorry, this message appears to be spam (#5.6.0)

I hope this gets cleared up today, clients are not receiving invoices for their transactions. :(
 
Hi Antic

I just replied to your private message but I just checked and my script is running fine this AM and I have had no error emails come through in the last 24 errors.
 
Thanks George, I've changed "remove" to "mark as spam" on an account I was BCC'ing to, so hopefully that will work. Thanks for passing that on.. not the first thing that pops to mind. :rolleyes:

Jodo, please consider:

This is pretty silly - it seems CDO is throwing an error if even ONE recipient (or CC or BCC) is an address on your network and has "remove" set for spam handling. It should not crash CDO while sending! CDO should exit normally so scripts can complete, and let spam processing occur separately - it should not interfere with scripts.

[ed] These are false-positives of course. I've mentioned this before, it seems SpamAssassin is complaining about the MSGID that CDO assigns. SA gives it over *3* spam points. That has to be addressed. If that alone was corrected, we would not have a problem.
 
These are false-positives of course. I've mentioned this before, it seems SpamAssassin is complaining about the MSGID that CDO assigns. SA gives it over *3* spam points. That has to be addressed. If that alone was corrected, we would not have a problem.
Click to expand...

I've already reduced the scores yesterday, are you still seeing the issue?
This is caused by recent spamassassin rule updates and not the Hsphere updates.
However, i'll disable the rule completely if you can confirm the problem still exists and that you atleast have spam settings set to Normal, no less.

This is pretty silly - it seems CDO is throwing an error if even ONE recipient (or CC or BCC) is an address on your network and has "remove" set for spam handling. It should not crash CDO while sending! CDO should exit normally so scripts can complete, and let spam processing occur separately - it should not interfere with scripts.
Click to expand...
This is how CDO is designed if you are using a remote SMTP. They have provided an option of setting "sendusing" to 1 where you message will be queued instead of delivery in realtime, but it is almost equal to using localhost direct.
 
tanmaya said:
I've already reduced the scores yesterday, are you still seeing the issue? This is caused by recent spamassassin rule updates and not the Hsphere updates. However, i'll disable the rule completely if you can confirm the problem still exists and that you atleast have spam settings set to Normal, no less.
Click to expand...

Thanks Tanmaya, my test script did encounter the error again a few minutes ago, but now it's working ok. Spam settings are normal, and set to "remove". As a precaution, I've added the FROM address of these notifications to the Whitelist of recipients hosted here.

tanmaya said:
This is how CDO is designed if you are using a remote SMTP. They have provided an option of setting "sendusing" to 1 where you message will be queued instead of delivery in realtime, but it is almost equal to using localhost direct.
Click to expand...

I thought if Sendusing was set to 1, it would use localhost by default? So are you saying I can use SMTP authentication *and* queuing at the same time to speed things up?
 
Confirmed that the rule "FH_MSGID_01C67 Special MSGID" isn't being tripped by my invoice emails anymore. X-Spam-Status header is now:

X-Spam-Status: No, score=3.4 required=7.0 tests=HTML_IMAGE_ONLY_28, HTML_MESSAGE, RDNS_NONE, SHORT_HELO_AND_INLINE_IMAGE

It's unfortunate that the rule change will be reset next time SpamAssassin is updated... they should allow you to retain rule changes. :(

Apparently SA checks for "$" in the MSGID and if the X-Mailer is Outlook it passes it. But CDO also puts "$" in the MSGID but SA doesn't seem to check for X-Mailer of CDO, only Outlook.
 
As state in another thread, i'll probably disable all these new rules as they are being more pain than help for our customers.
 
Good news for us I think but sorry it's being a pain for you guys. Or rather that we're being a pain. :)
 
You must log in or register to reply here.
Back
Top