MIME Mail

[digitalfusion]

I have written a script that sends MIME-encoded email with attachments.[nbsp][nbsp]This script works perfectly, and I've sent mail to yahoo accounts, aol accounts, and local university accounts with no trouble.[nbsp][nbsp]However, when I send email to a FutureQuest-hosted email account and open it with Outlook, it doesn't recognize the attachment; the binary stream is just part of the message.[nbsp][nbsp]Also, it shows the Content-Type line even if headers are not being shown.[nbsp][nbsp]I'd think it's me, but it seems to work flawlessly on every other system.[nbsp][nbsp]Any ideas why this would be happening?[nbsp][nbsp]Thanks in advance for your help!

Sincerely,
Michael Dwyer

[Bruce]

It sounds like some of the headers are being modified or deleted in transport, however the FutureQuest mail servers do not touch any of the headers (other than adding Received lines).

Could you please post the complete headers, without modifications, from both a working copy of the received message and from a broken copy.
------------------
Bruce Guenter, FutureQuest
http://untroubled.org/

[digitalfusion]

These are the headers (although this same message works fine on AOL and Yahoo):

Return-Path: <PHP3@kozlin.com>
Delivered-To: mgdwyer@mailspool01.dyn.acsu.buffalo.edu
Received: (qmail 292 invoked from network); 22 May 2001 18:33:02 -0000
Received: from warmfront.acsu.buffalo.edu (HELO front.acsu.buffalo.edu) (128.205.6.88)
[nbsp][nbsp]by mail2 with SMTP; 22 May 2001 18:33:02 -0000
Received: (qmail 8789 invoked by uid 27718); 22 May 2001 18:33:01 -0000
Received: (qmail 8769 invoked from network); 22 May 2001 18:33:01 -0000
Received: from unknown (HELO escher.futurequest.net) (63.144.246.2)
[nbsp][nbsp]by front with SMTP; 22 May 2001 18:33:01 -0000
Received: (qmail 31310 invoked by uid 98); 22 May 2001 18:33:22 -0000
Date: 22 May 2001 18:33:22 -0000
Message-ID: <20010522183322.31309.qmail@escher.futurequest.net>
To: &quot;Jeff Kozlin&quot; <mgdwyer@acsu.buffalo.edu>
Subject: Candidate Form: Testing
From: &quot;Testing&quot; <Testing@escher.futurequest.net>
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary=&quot;=_c410e391cc856faf80a683c3fd8624c3&quot;

The only difference between working and not working is the fact that the following line:

Content-Type: multipart/mixed; boundary=&quot;=_c410e391cc856faf80a683c3fd8624c3&quot;

is part of the message, not the headers, when I open it from FutureQuest; the headers end at MIME-Version.[nbsp][nbsp]On other servers, it is included as part of the headers.

Thanks so much for any help you can provide. This has been a real pain to track down ;)

Sincerely,
Mike<!-- NO_AUTO_LINK -->
[This message has been edited by digitalfusion (edited 05-22-01@5:17 pm)]

[Terra]

Ok, let me clarify something before proceeding...

You have the PHP program running on 'kozlin.com' ??

This *exact same PHP script* has the following behavior:

1) PHP + MIME mail --> outside email server (AOL/Yahoo/etc) == OK
2) PHP + MIME mail --> FutureQuest hosted email address == Broken

Is the above a safe assumption?

The important bits being that the PHP script on FutureQuest servers IS sending both of the emails with one 'Broken' and the other 'OK'...

Right now I'm just trying to isolate the pieces of this puzzle, understand it's behavior and hopefully formulate some type of resolve...

--
Terra
--It's important that our servers all speak the same language amongst themselves--
FutureQuest

[digitalfusion]

Yes, it's the exact same script.[nbsp][nbsp]In fact, I've tried the exact same message, sending it to two addesses at the same time during the same script execution.[nbsp][nbsp]When I do that, it works on the other mail clients, but just gives me the raw email through futurequest.[nbsp][nbsp]I'm downloading the messages through Outlook.[nbsp][nbsp]However, I've also gotten them from an Adelphia account with Outlook and they work fine.[nbsp][nbsp]The only thing I can think of is that I'm doing something slightly wrong that some server's are &quot;smart&quot; enough to catch and fix??[nbsp][nbsp]Could that be it or am I way off base here? And if that is it, I still have no idea what it is . . . everything seems ok to me with the headers.

Thanks again for all your help, I really appreciate it.

-Mike
[This message has been edited by digitalfusion (edited 05-22-01@7:20 pm)]

[Terra]

Paste the mail function (with arguments) that sends the email...

I'm assuming it's in:
employer_parse.php
function send

if that is correct, paste in that function sandwiched in '[ code ]function[ /code ]' tags...

It may very well be a '\r\n' issue where sendmail servers will 'auto-correct' certain things whereas QMail has a 'hands-off' policy (as it *should*)...

--
Terra
--the path begins to unfold--
FutureQuest
<!-- NO_AUTO_LINK -->
[This message has been edited by ccTech (edited 05-22-01@7:58 pm)]

[digitalfusion]

Actually, it's in candidate_parse.[nbsp][nbsp]The employer one doesn't use attachments and works fine.[nbsp][nbsp]The actual functions that create the mail are from a class by Richard Heyes, and it's pretty long (almost 250 lines).[nbsp][nbsp]So, I've temporarily posted it on the site at:

http://www.kozlin.com/candidate_parse.php.html

Thanks,
-Mike

[Bruce]

Maybe I'm being obtuse, but I don't see where this script actually sends the message.[nbsp][nbsp]I mean, html_mime_mail->send() looks like it's supposed to send the message, and it gets called twice at the bottom of the PHP, but it never actually calls the mail() function to send the message.
------------------
Bruce Guenter, FutureQuest
http://untroubled.org/

[digitalfusion]

I'm sorry, it was the fact that i made it an HTML file.[nbsp][nbsp]It was cutting stuff out, so I've made it a text file and it should all be there now.

http://www.kozlin.com/candidate_parse.txt

Thanks,
-Mike[nbsp]

[Terra]

I'll give you a PHP tip...

copy 'candidate_parse.php' to 'candidate_parse.phps'

I think you'll like the results... :)

--
Terra
--I must admit, watching the 'blew' bird was a riot!--
FutureQuest

[Bruce]

OK, that looks more reasonable.[nbsp][nbsp]In fact, I still don't see a problem.[nbsp][nbsp]Could you copy my email on one of these broken messages?
------------------
Bruce Guenter, FutureQuest
http://untroubled.org/

[digitalfusion]

Wow, thanks Terra, I wish I would've known that before![nbsp][nbsp]Thanks[nbsp][nbsp]for the tip.[nbsp][nbsp]That's the kind of thing that makes me wonder what else I don't know . . . ;)

Bruce, I put you in the email as well, let me know if you need anything else.

Thanks again for all the help!

-Mike

[Terra]

Ok, this just does not make any sense...

You state there is an issue of an extra line feed between the following:
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary=&quot;=_c410e391cc856faf80a683c3fd8624c3&quot;

However, 'multipart/mixed' is only defined in one place...[nbsp][nbsp]It goes into the Class headers array and is later imploded with '\r\n'

$this->headers[] = 'MIME-Version: 1.0';
$this->headers[] = 'Content-Type: multipart/mixed;'. ' ' .'boundary=&quot;'.$boundary.'&quot;';

As you can see - the array building is happening back to back and I did not see where an extra '\r\n' was being spliced in...

Also, I don't see why our QMail servers would muck around with the 'MIME' header lines...[nbsp][nbsp]There is no logic or reason in doing so...

So, to clarify:
1) in *all* cases:
regular email headers
MIME-Version: 1.0

stays glued to the email headers?

2) The problem is a rogue extra line feed inserting itself in between of the 'Mime-Version' and 'Content-Type' headers

3) Have you contacted the Class Programs author?
Richard Heyes <richard.heyes@heyes-computing.net>

and asked if he's ever heard of such a problem...

4) Have you tried other email programs **other** than Outlook?

To be quite honest, I have not a clue as to why you are seeing what you are seeing...

--
Terra
--This issue is starting to behave like another Microsoft conspiracy--
FutureQuest

[digitalfusion]

Ok, thanks for the advice.[nbsp][nbsp]I don't get it either, everything seems to be right, and I haven't had any trouble with your QMail servers receiving any other emails with attachments.[nbsp][nbsp]I guess I'll try contacting the author and crossing my fingers . . .

Thanks again,
Mike

[Bruce]

I just received the test post you sent to me, and I see no problems with it.[nbsp][nbsp]There are two parts, one with the plain text listing the candidate details, and one with the &quot;Branch Page.doc&quot; file, all with the proper headers and MIME encoding etc.
------------------
Bruce Guenter, FutureQuest
http://untroubled.org/

[digitalfusion]

Ok, makes less and less sense here . . .[nbsp][nbsp] Why wouldn't it be working from this one domain then?[nbsp][nbsp]I've tried getting the messages from Outlook and from Netscape.[nbsp][nbsp]Are you using a different mail client?

[Bruce]

I am using Mutt as my mail client, which is a UNIX program, however I have mail directly delivered to my computer rather than fetching it through POP.[nbsp][nbsp]Just to make an apples-to-apples comparison, please try another test message to test@untroubled.org.[nbsp][nbsp]This is a POP account hosted by FutureQuest, which should behave identically to yours (it's even on the same server from what I can tell).
------------------
Bruce Guenter, FutureQuest
http://untroubled.org/

[Bruce]

I have received your second test post in my POP mailbox, and I think I see the problem.[nbsp][nbsp]There is an extra CR (&quot;\r&quot; in PHP) at the end of the MIME-Version: and the Content-Type: headers.[nbsp][nbsp]Outlook is mis-interpreting this extra CR as an end of line (LF or &quot;\n&quot; marks the real end of line).

The reason that you are only seeing the problem on FutureQuest is because of a low-level detail in how messages are transmitted between servers causes those extra CRs to be stripped in some cases.[nbsp][nbsp]Specifically, SMTP (the protocol used to transmit email) specifies that all lines end with CR and then LF.[nbsp][nbsp]The server sees CR CR LF, and silently drops the extraneous CR.[nbsp][nbsp]When you sent to your FutureQuest account, it never left the server (since the sending program and the receiving mailbox are on the same server), and thus never had the extra CR stripped from it.

I would encourage you to modify the script to replace every instance of &quot;\r\n&quot; with just &quot;\n&quot; to work around this bug in Outlook.[nbsp][nbsp]You would also be wise to advise the author of the script of this.
------------------
Bruce Guenter, FutureQuest
http://untroubled.org/

[digitalfusion]

Yep, that did it.[nbsp][nbsp]Thanks so much for the help![nbsp][nbsp]I don't think I would ever have figured that out on my own.[nbsp][nbsp]I'll email the author and let him know about it, too.

Thanks again for all the help.

Sincerely,
Mike