Form attachments - encoding issue

[mark70]

Hi.
On a scale of development talent, I'm a 4 out of 10 so here's hoping I don't embarrass myself too badly.

I've studied these postings on multiple occasions and haven't yet located the 'fix' for my situation.

I'm using FormMail 2.15 on a Debian Linux server.
Forms are accepted and received well enough, but attachments do not show up as actual attachments. They are encoded and embedded into email.

I have double-checked and do believe that I have proper code and that my server is set properly to allow for attachments.

Here is a link to the form: http://www.savantconsulting.com/cand...es_resume3.htm
Below is a sample of the email output. Any ideas at this point would be entirely appreciated.
Thx.

Content-Type: multipart/mixed; boundary="PART83330b13ec2f1c60e49cca9926bc59e7"

Message-Id: <20040827153647.481DF1B1E043@mail.giantworks.net>

Date: Fri, 27 Aug 2004 08:36:47 -0700 (PDT)

(Your mail reader should not show this text. If it does

you may need to upgrade to more modern software.)

--PART83330b13ec2f1c60e49cca9926bc59e7

Content-Type: text/plain; charset=ISO-8859-1



email: test@test.com

realname:

redirect: http://www.stoneinteractive.com/sites/gee

first_name: test

last_name: test

phone_number: test

most_recent_employer: test

most_recent_title: test

salary: test

submit: Send Us Your Comments --PART83330b13ec2f1c60e49cca9926bc59e7

Content-Type: text/plain; name="config.txt"; charset=ISO-8859-1

Content-Transfer-Encoding: base64

Content-Disposition: attachment; filename="config.txt"



ZnVuY3Rpb24gaW5pdCgpDQp7DQovL01haW4gTWVudSBpdGVtczoNCgltZW51c1swXSA9IG5ldyBt

ZW51KDE5NywgInZlcnRpY2FsIiwgMjgsIDI1MywgMCwgMCwgIiNFQkYzRjYiLCAiI0RDRTZFRiIs

(cut out some 100 lines here)
RVZFUllUSElORyBBRERFRCBNVVNUIEJFIEFCT1ZFIFRISVMgTElORS4=
--PART83330b13ec2f1c60e49cca9926bc59e7--



==================================

[russellr]

Hi,

I'd like $10 for every time I've seen this problem.

Don't worry, you've probably done all the right things and it's bad software on your server that's causing the problem.

Basically, the "official standard" (called an RFC) says that lines in the body of an email should be terminated with carriage-return + line-feed, but that there doesn't actually have to be any lines (it can be one long line). Line-feeds alone don't terminate a line.

Typically, email creation software will terminate lines with a single line-feed and that's perfectly OK - it's just that they are not "lines" in the official sense.

But, some server software sees the single line-feeds and treats them as proper lines and then somehow gets everything wrong and decides to double-space all lines!

Confused? Don't worry....you don't need to understand that (I'm not sure I understand what the server software thinks it's doing, either).

You're lucky you're using version 2.15. The solution is to look for the configuration setting in FormMail called "BODY_LF".

You'll see the following two lines:

//define("BODY_LF","\n");  // the old default: just LF
define("BODY_LF","\r\n");  // the new default: use this for CR+LF 

Simply change them to this:

define("BODY_LF","\n");  // the old default: just LF
//define("BODY_LF","\r\n");  // the new default: use this for CR+LF 

That should resolve the problem.

If not, we may have to do more investigation.

[mark70]

Thanks much for the quick reply.

I made the suggested change(s) and have not yet noticed any improvement in the emails that I receive after form submission.

Your instructions speak to line breaks of text within emails. I'm a bit confused because I'm not seeing the connection between that and the issue I'm experiencing. I'm expecting emails to arrive with a file attached and - rather - the email arrives with the content of the attachment embedded in the email and it seems to be encoded in some way.

Here is a copy of what is received after making the requested changes. Any ideas for what we can try next? Thx.

Content-Type: multipart/mixed; boundary="PART842f9ddd442fcb52062eb7b8f7e1b2fb"

Message-Id: <20041006123003.A7AD21B1E041@mail.giantworks.net>

Date: Wed, 6 Oct 2004 05:30:03 -0700 (PDT)

(Your mail reader should not show this text. If it does

you may need to upgrade to more modern software.)

--PART842f9ddd442fcb52062eb7b8f7e1b2fb

Content-Type: text/plain; charset=ISO-8859-1



email: test@test.com

realname:

redirect: http://www.stoneinteractive.com/sites/gee

first_name: test2

last_name: test

phone_number: test

most_recent_employer: test

most_recent_title: test

salary: test

submit: Send Us Your Comments --PART842f9ddd442fcb52062eb7b8f7e1b2fb

Content-Type: text/richtext; name="resume.rtf"; charset=ISO-8859-1

Content-Transfer-Encoding: base64

Content-Disposition: attachment; filename="resume.rtf"



e1xydGYxXGFuc2lcYW5zaWNwZzEyNTJcZGVmZjBcZGVmbGFuZzEwMzN7XGZvbnR0Ymx7XGYwXGZz

d2lzc1xmY2hhcnNldDAgQXJpYWw7fX0NCntcKlxnZW5lcmF0b3IgTXNmdGVkaXQgNS40MS4xNS4x

NTAzO31cdmlld2tpbmQ0XHVjMVxwYXJkXGYwXGZzMjAgc2FtcGxlIHJlc3VtZVxwYXINCn0NCgA=

--PART842f9ddd442fcb52062eb7b8f7e1b2fb--



==================================

[russellr]

Hi,

The connection between the line terminations and the missing file attachment is as follows....

An attached file (or alternative mail view - such as HTML) is placed in the email using MIME format.

MIME format simply(!) specifies certain special headers at the top of the mail, and then the attachment is placed in the body of the mail with a special separator and some header fields.

The header fields must be line terminated correctly. If not, then the MIME logic in your mail reader cannot process the MIME format and cannot see the attached file.

Therefore, lines must be terminated correctly so your mail reader can understand the mail. If your server is doing the wrong thing (which yours appears to be doing) then the mail reader cannot understand the MIME format.

I'm concerned that you saw no change to the format of the email. You'll notice that your field lines are double-spaced. That's a problem and the change to BODY_LF should have fixed that.

Please double-check that you uploaded FormMail after you made the change and that your form is using the correct formmail.php.

The next step is to tell FormMail to terminate header lines incorrectly.

Near line 1092 in v2.15, you'll see this line:

define("HEAD_CRLF","\r\n"); 

Change it to look like this:

define("HEAD_CRLF","\n"); 

If that still doesn't make any difference, I'd suspect that your server uploads of formmail.php aren't working properly.

If it fixes the problem, set BODY_LF back the way it should be, and test again. It's important to remain as close to the email standard as possible. If you need BODY_LF and HEAD_CRLF both set incorrectly, then that will have to do.

If it doesn't fix the problem, please email your form and formmail.php to me at supportstaff AT tectite DOT com.

BTW, the last person who had this problem needed me to log into their server to diagnose the problem....I hope we don't get to that, but the offer is there if you need it. (And his server turned out to need both HEAD_CRLF and BODY_LF set incorrectly to the "\n").

[mark70]

HOT DOG!

The attachment showed up as hoped. Must say that I am more than a little impressed with the effort on Tectite's end. Thanks much.

[russellr]

Excellent!

Let me know if you need any further assistance.

And, please consider providing a link to our website from your's. It really does help us to continue to provide free software and free support.