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>
From: "Xxxxxxx Xxxxx" <xxxxx@xxxxxxx.net>
Reply-To: xxxxx@xxxxxxx.net
MIME-Version: 1.0
Content-type: text/html; charset=iso-8859-1
X-Mailer: PHP/4.3.2

but can't tell if that'll make a difference...

Roberto F.
LogSat Software

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
Return-Path: <xxxxx@xxxxxxx.net>
Content-type: text/html; charset=iso-8859-1
From: "Xxxxxxx Xxxxx" <xxxxx@xxxxxxx.net>
Reply-To: xxxxx@xxxxxxx.net
X-Mailer: PHP/4.3.2

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
Return-Path: <xxxxx@xxxxxxx.net>
Received: from vmc-ext.prodigy.net (207.115.63.88)
  by mta820.mail.sc5.yahoo.com with SMTP; Mon, 09 Feb 2004 22:01:49 -0800
X-Originating-IP: [66.235.192.173]
Received: from hostXXX.ipowerweb.com (hostXXX.ipowerweb.com [66.235.192.173])
 by vmc-ext.prodigy.net (8.12.10/8.12.10) with SMTP id i1A61l0x045636
 for <xxxxxxx@xxxxxxxxx.xxx>; Tue, 10 Feb 2004 01:01:48 -0500
Received: (qmail 91267 invoked by uid 80); 10 Feb 2004 05:55:28 -0000
Date: 10 Feb 2004 05:55:28 -0000
Message-ID: <20040210055528.91266.qmail@hostXXX.ipowerweb.com>
To: xxxxxxx@xxxxxxxxx.net
Subject: Wednesday, February 4, 2004
MIME-Version: 1.0
Content-type: text/html; charset=iso-8859-1
From: "Xxxxxxx Xxxxxx" <xxxxx@xxxxxxx.net>
Reply-To: xxxxx@xxxxxxx.net
X-Mailer: PHP/4.3.2

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

Eddo,

That we could only tell by looking at your original, unmodified, headers...

Roberto F.
LogSat Software

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
MIME-Version: 1.0
From: xxxxx@xxxxxxx.xxx
X-Fix: NTMail fixed non RFC822 compliant EMail message

Content-type: text/html; charset=iso-8859-1

From: "xxxxxxx xxxxxx" <xxxxx@xxxxxxx.xxx>
Reply-To: xxxxx@xxxxxxx.xxx
X-Mailer: PHP/4.3.2

X-Server: LogSat Software SMTP Server - Unlicensed Evaluation Copy

<HTML>
<HEAD>
(etc for rest of email HTML message...)

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.
LogSat Software

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

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-

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
5.06.0016/NT7769.00.fb7a68ab) with ESMTP id fitrmaaa for
xxxxxxxxxxxxx@xxxxxxx.xxx; Wed, 21 Jan 2004 03:17:31 -0800
Received: from 66.235.192.173 by 207.212.244.6 (LogSat Software SMTP
Server - Unlicensed Evaluation Copy) Wed, 21 Jan 2004 03:21:34 -0800
Received: (qmail 12779 invoked by uid 80); 21 Jan 2004 11:19:27 -0000
Date: 21 Jan 2004 11:19:27 -0000
Message-ID: <20040121111927.12778.qmail@hostxxx.ipowerweb.com>
To: xxxxxxxxxxxxx@xxxxxxx.xxx
Subject: Wednesday, January 21st, 2004
MIME-Version: 1.0
From: xxxxx@xxxxxxx.xxx
X-Fix: NTMail fixed non RFC822 compliant EMail message

Content-type: text/html; charset=iso-8859-1

From: "xxxxxxx xxxxxx" <xxxxx@xxxxxxx.xxx>
Reply-To: xxxxx@xxxxxxx.xxx
X-Mailer: PHP/4.3.2

X-Server: LogSat Software SMTP Server - Unlicensed Evaluation Copy

<HTML>
<HEAD>
(etc for rest of email HTML message...)

------------------------------------------------------------------------

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

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.
LogSat Software

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