After setting up CAS and OE in a virtual machine, I sent an e-mail to the accounts used by OE and monitored by CAS. A challenge got sent back to the sender (me using another account). However, that challenge went into the Spam folder. This was up on the mail server for my e-mail account. Since I use POP to access this account, my local e-mail client would never see this challenge. POP only understands the concept of a mailbox (which is the Inbox folder when using the webmail interface) so any e-mails delivered to the Junk, Spam, or Trash folders on the server cannot be seen by my local e-mail client. It was because I was using the webmail interface to my account that I realized that the challenge got tagged as spam.
The spam filtering at my ISP is not configurable. Either it is on or off. Currently it is on. I might consider turning it off except for problems already noted in my other post about using non-Microsoft e-mail clients which obviates me from actually adopting CAS as my antispam solution (but I wanted to do some additional testing anyway). Obviously I can turn off my ISP’s spam filtering on my e-mail account but the vast majority of users will have spam filtering enabled on their account. So the problem here is that the challenge will end up in the sender’s Spam folder which doesn’t get downloaded to their local e-mail client when using POP.
Because I cannot do any configuration of the server-side antispam filtering provided by my ISP, I can’t really tell why it decided the challenge sent by CAS was spam. I have read several articles over many years where some ISPs have decided all challenges qualify as spam and will block them. Even if not the case, the challenge runs the gauntlet of antispam filters employed before the user will ever have the opportunity of retrieving it using a local e-mail client. Below are the headers in the challenge e-mail that was received back in my sending account (the one used to send the original e-mail and expected to receive the challenge):
Date: Fri, 25 Jul 2008 22:01:15 +0000 (GMT)
X-Comment: Sending client does not conform to RFC822 minimum requirements
X-Comment: Date has been added by Maillennium
Received: from omta12.westchester.pa.mail.comcast.net ([76.96.62.44])
by alnrmxc18.comcast.net (alnrmxc18) with ESMTP
id <20080725220115a1800r3qj1e>; Fri, 25 Jul 2008 22:01:15 +0000
X-Originating-IP: [76.96.62.44]
Received: from WINXP-VMWARE ([69.180.133.66])
by OMTA12.westchester.pa.mail.comcast.net with comcast
id uN1E1Z0041S6wJD3YN1EQK; Fri, 25 Jul 2008 22:01:15 +0000
X-CAA-SPAM: 120
X-Authority-Analysis: v=1.0 c=0 p=brvf1KVgEdaXR0LXmRMA:9 a=YFMRg3r0wlUA:10
a=HCy-yVXEAAAA:8
X-Authority-Analysis: v=1.0 c=0 p=brvf1KVgEdaXR0LXmRMA:9 a=YFMRg3r0wlUA:10
a=HCy-yVXEAAAA:8
Subject: Comodo AntiSpam Alert from Lee Hodsdon
X-Comodo-AntiSpamRFA:CAS_COMBINED_RFA
From:
To:
MIME-Version: 1.0
Content-Type: multipart/related;
boundary=“----=_NextPart_000_000A_01C304D4.BC543940”
Importance: High
X-MSMail-Priority: High
X-Comment: Sending client does not conform to RFC822 minimum requirements
I’m assuming that was added by my sending account’s mail server (the one that originated the test e-mail for which the receiving mail account would send back a challenge). Apparently my ISP doesn’t like how CAS generated the headers in its challenge e-mail.
X-Comment: Date has been added by Maillennium
Does that mean that CAS omitted the Date header in its challenge e-mail?
From:
To:
That means CAS inserted a From and To header that both had the receiving account’s e-mail address. These “headers” are not used in specifying the recipient of an e-mail. They are part of the body of the e-mail. An e-mail client aggregates the recipients from the To, Cc, and Bcc fields within its UI and compiles a list of recipients. It then sends a RCPT-TO command to the SMTP mail host, one for each recipient. That is followed by the e-mail client sending a DATA command that contains the content of the message. The Date, Subject, To, Cc, and From “headers” are added by the e-mail client into the body of the message (header section, blank delimiter line, body) and sent by the DATA command. So if there is a problem with the From, To, and Date headers then it was a problem in the e-mail client that composed the data of the message since those were in the body of the message generated by the e-mail client. Maybe that is what the non-RFC compliant header was about in that the sender (From) and recipient (To) headers point at the same e-mail address, and that the To header does not match the actual recipient of the challenge e-mail. The receiving mail account is shown in the To header in the challenge generated by CAS when it should’ve had the sending mail account to which that challenge was sent.
I don’t which X-headers were added by CAS, which were added by the receiving account’s SMTP mail host (that was sending back the challenge), and which were added by the sending account’s SMTP mail host (that received the challenge). Maybe the ISP’s antispam filter triggered on one of those. It is also possible that it didn’t like the content of the Subject header.
For whatever reason, the ISP’s antispam filter determined that the challenge e-mail sent by CAS was spam and moved it into the Spam folder up on the mail server for that account. If POP is used, those spam-suspect e-mails moved into a folder other than Inbox won’t be downloaded into a local POP e-mail client. So the original sender of an e-mail that got back a challenge won’t see it. Yes, I can disable the server-side antispam filter on my account but that won’t affect the antispam filtering on anyone else’s account that is trying to send e-mail to me.
Since, as far as I know, there is no RFC to yet standardize on how challenge-response schemes should behave and how a mail host should handle the challenges then it seems this C-R scheme can easily run afoul of antispam filters. They send me e-mail, I send back a challenge, but they never see the challenge so their e-mail never gets validated to end up in my local e-mail client to see it. If I have to continually review the quarantine or pending queue in CAS then I’ve defeated the whole point of an antispam scheme that supposedly never bothers me with spam. I get that already with passive antispam schemes, like using DNSBLs, country-IP blocks, and Bayesian filters, like in SpamPal.
On the flip side of standardization, I have seen technical arguments that discuss how bogus e-mails can be crafted to look like challenges to get past a challenge gateway or antispam filters and get delivered into the target mailbox. So I’m not sure what is the solution but it does seem that as it is now implemented that I could lose a lot of e-mails from non-whitelisted senders because my challenges run afoul of antispam filters.