can spamfilter, if not configured properly, pass HTML as plain text? |
Post Reply 
|
| Author | |
eddo 
Guest Group 
|
 Post Options
 Thanks(0)
 Quote Reply
 Topic: can spamfilter, if not configured properly, pass HTML as plain text?Posted: 03 February 2004 at 10:43pm |
|
I send out HTML emails once a week to under 40 people from a website. I know of one member who receives these as plain text, even though the "Content-type: text/html;" line is present, even though she has OE6, just as I have (and I have no problems), and even though, having gone over all her settings, they all seem proper. The only thing different I can see, is that there is an additional header line (in these HTML emails she receives, as compared to my receives, that says "X-Server: LogSat Software SMTP Server - Unlicensed Evaluation Copy", which tells me her ISP is using your product. That's the ONLY difference I can find in her setup, and it makes me suspect that somehow her ISP is not using your product properly, and it is passing on my HTML emails to her as plain text, which is a pain. Is this a possibility with your product, and if so, is there a way to fix it? (What could I say to her ISP to tell them how to prevent this from happening in the future). Thanks, -eddo
|
|
 |
|
|
LogSat
Admin Group 
Joined: 25 January 2005 Location: United States Status: Offline Points: 4104 |
Post Options
Thanks(0)
Quote Reply
Posted: 04 February 2004 at 10:46pm |
|
Eddo, It would be best if you asked your member to contact her ISP directly. Even though from what you posted it would seem the ISP is running an unlicensed copy of our software we'll be helping them anyways. Not knowing what settings the ISP is using won't make this simple to troubleshoot. If you could post the full headers of the email she is receiving (changing her email address for privacy) there's a chance we may see what's wrong from the headers themselves. Roberto F. |
|
|
|
|
eddo
Guest Group
|
Post Options
Thanks(0)
Quote Reply
Posted: 08 February 2004 at 2:25am |
|
Hi Roberto - thanks for the reply. Here's the headers of one of my failed emails with xxxx's over private stuff (they all are coming over as plain text to her Outlook Express client): Received: from [207.212.244.6] by mail.solanowebdesign.com (NTMail ------------------------------------------------------------------------ Looking a the full headers, I see the "X-Fix: NTMail fixed non RFC822 compliant EMail message" line. This is probably the source of the problem? But what is non-compliant? -eddo |
|
|
|
|
eric
Guest Group
|
Post Options
Thanks(0)
Quote Reply
Posted: 08 February 2004 at 4:36am |
|
you are causing the problem... sending non-rfc822 compliant mail will also not pass my filters, due to the recent outbreak of gif/jpg http ahref body mails from spammers... please note, that i say you are causing....
spammers are of course the real problem .. i am also presenting our new outlook 2003 users with display html as usascii txt policy wise, because of the hidden read tags in html.(aka hitbox tags)
please consider using : internal domain links only in your body (no outside own source domain links) use rich txt mail instead (same display format can be done) spamfilter does always pass html mail properly, by default. however some bofh mailadmins like me, configure it to kill off all asian and us html mail. (we have customers only in europe, thats why...) -eric- |
|
|
|
|
eddo
Guest Group
|
Post Options
Thanks(0)
Quote Reply
Posted: 08 February 2004 at 6:47pm |
|
Hi Eric, Fine - it's all my fault. I'm sure it was. That's why my question was "how am I non-rfc822 compliant?". I submitted the headers hoping someone could look at them and tell me why their NTMail (I'm pretty sure now this has nothing to do with LogSat's spam processing, but I could be wrong about that yet) saw my email as non RFC822 compliant. I'm not using any outside source domain tags (really, just one gif which is a big banner title with our group's name on it. Anyway, it wasn't rejected because of that.) Also, keep in mind that my emails are not being judged (evidently) as spam - they are not being bounced or deleted. They are 'fixed' and passed on to the recipient. If you have any clue why I'm non-rfc822 compliant, or can point me to a place on the web which can explain the requirements for rfc822 compliancy in terms a normal web-geek can understand, I'd be much appreciative. thanks, - eddo |
|
|
|
|
LogSat
Admin Group
Joined: 25 January 2005 Location: United States Status: Offline Points: 4104 |
Post Options
Thanks(0)
Quote Reply
Posted: 09 February 2004 at 12:25am |
|
Eddo, In "plain english", rather than in complicated RFC language, I believe the problem is the following. In an email, all of the headers are sent in sequence, one after the other. As soon as there is an empty line, the the headers stop and the email body begins. If you copied/pasted the msg correctly, (and if our forum ASP code did not mess up your formatting), then you entered the following: Subject: Wednesday, January 21st, 2004 Please note the blank line after the X-Fix header. That tells the email client that the headers are finished, and that whatever follows is part of the message. Thus the Content-type header is not seen, as it is now considered part of the body. It would seem that NTMail may have indeed fixed something that was non-RFC compliant, but then made a mistake itself in breaking up the rest of the headers by adding an extra CRLF sequence after that header. Roberto F. |
|
|
|
|
eddo
Guest Group
|
Post Options
Thanks(0)
Quote Reply
Posted: 09 February 2004 at 12:43am |
|
I'm sure you got it, Roberto - thanks a lot. The blank line following the 'X-Fix' line output by NTMail was indeed there in the full message source as I examined it in its 'received' state. I have emailed her ISP about this. I still don't know why their NTMail kicked in thinking it needed to 'fix' my headers - is the fact that the 'X-Fix:' line immediately follows their "From:" header line an indication that I had something not kosher with my from header line? NOTE: the "From: " header line it follows is NOT my "From" header line, which occurred after (immediately after, not after a blank line as you see it was delivered) the Content-type: line.
|
|
|
|
|
LogSat
Admin Group
Joined: 25 January 2005 Location: United States Status: Offline Points: 4104 |
Post Options
Thanks(0)
Quote Reply
Posted: 09 February 2004 at 11:25pm |
|
Eddo, That we could only tell by looking at your original, unmodified, headers... Roberto F. |
|
|
|
|
eddo
Guest Group
|
Post Options
Thanks(0)
Quote Reply
Posted: 10 February 2004 at 1:27am |
|
Roberto, How can I know EXACTLY what my headers looked like, if what you imply is true, i.e., that ISP processing can change them all around? I am doing the coding on this PHP-driven website. I can tell you that my webhost uses QMAIL for mail processing, and that I code the following as 'additional headers' when I call the php function mail() (xxx's cover addresses for privacy): MIME-Version: 1.0 Emails are sent to QMAIL via PHP's mail() function, which looks like: mail(email_address, subject, bodytext, additional_headers) Qmail generates the To: and Subject: header lines from the passed arguments (along with the Date header, etc). Note that a characteristic of Qmail is that I can't put my own To: header line in the 'additional_heaaders - if I do, the email gets sent twice! I can then give you the headers as I receive them from my ISP (SBC, which has no problems at all with RFC822 compliancy): X-Apparently-To: xxxxxxx@xxxxxxxxx.net via web80507.mail.yahoo.com; Mon, 09 Feb 2004 22:01:49 -0800 Note that the "Return-Path:" header isn't where I had it at all in my 'additional headers' as passed to the mail() function - that's why I say I can't be SURE exactly how my headers look when they are emailed by my webhost. Still, nothing I can see looks non-compliant to RFC822. This ISP I'm dealing with is SUPER anal-retentive as far as how it screens emails, by the way. Several months back they were bouncing any email that had the string 'yahoo.com' in the headers as 'spam'. My ISP is SBC, which happens to use yahoo.com mail as their mail processor, and thus 1000's of people automatically became 'spammers' in the eyes of this ISP. I sent them headers when requested but got no response from them at all. After a repeat of no response a week later, I just gave up. Now they've gotten wise because my personal email through them is no longer being bounced as spam. Sigh. And thanks a lot, Roberto, for staying with this, even though we're pretty far past the point where your LogSat software has anything to do with this. By the way, I will be telling these jerks that LogSat would appreciate it if they start using a licensed version of your software! -eddo |
|
|
|
|
LogSat
Admin Group
Joined: 25 January 2005 Location: United States Status: Offline Points: 4104 |
Post Options
Thanks(0)
Quote Reply
Posted: 11 February 2004 at 12:11am |
|
Eddo, SBC is also re-arranging the headers in an unusual way, so you can't really tell how your mailer sends them out by sending the email to SBC. You should really send the test email either to a "good" ISP who handles mail correctly, or you could even configure the web mailer to send you the email. You'll need an SMTP server running on your PC that will provide SMTP traces of the commands sent. You could also use SpamFilter which does provide some extra debugging tracing on screen so you can follow the commands. From your post, I'd re-arrange your headers as follows: Return-Path: <xxxxx@xxxxxxx.net> but can't tell if that'll make a difference... Roberto F. |
|
|
|
Topic Options|
Post Reply
|
|
Tweet
|
| Forum Jump | Forum Permissions You cannot post new topics in this forum You cannot reply to topics in this forum You cannot delete your posts in this forum You cannot edit your posts in this forum You cannot create polls in this forum You cannot vote in polls in this forum |
This page was generated in 0.227 seconds.