I have a custom web based contact management system that we built in PHP to track contacts and recently starting checking our Google e-mail box using IMAP and then, if that contact is in our contact management system:
Copying the message into a MySQL database table that's associated with that contact
Marking that contact to follow up with that day
Archiving the message in Gmail
Everything seems to be working great, EXCEPT... every so many emails we get a really garbled message that looks like this:
FABRRRQAUUUUAJXDjxZrUtzNFa2UMwjYj5YnYgZ74Ndwa4bwfzqmpH3/wDZjTcl
CnKdr2Fa7SJP+Ek8S/8AQJX/AMB5P8aZN4s162j33GmxxrnG54XUfqa6ysHxp/yA/wDtqv8AWuej
jFUqKDgtSpQsr3L13r4tPDcOoShBcTxgog6FiP5CsrwtpjuzavekvcTZKFuwPf8AH+VZOlwS+Iby
1jlBFnZRKhGeDjt9Sf0Fd0qhVCqAABgA
I go back and check the message and it appears to be only text, so I don't think it is an image. Any idea how to prevent that?
Thanks in advance.
Sincerely,
James
The example you provided looks like it is base64 encoded. The headers of the email message will tell you how to handle the content of the email message.
For example, the following defines an email message where the body is plain text, but it is stored as being base64 encoded. I have "x"ed out the privacy sensitive information.
Received: from xxxxxxxxx ([xxx.xx.xx.xxx]) by xxxxxxxxxx.xxx.xxxxxxxxxxxxxxx.xxx with Microsoft SMTPSVC(6.0.3790.3959);
Wed, 29 Apr 2009 21:29:16 +0000
Received: from xxxx-xxx-xxxxxx ([xxx.xx.xxx.xxxx]) by xxxxxxxx ; Wed, 29 Apr 2009 15:29:16
-0600
Message-ID: <AADB29A7-AAED-4068-B4A8-300E3B0D93AB#localhost>
MIME-Version: 1.0
From: xxxxxxxxxx#xxxxxxxxxxxxxxx.com
To: xxxxxxxxxx#xxxxxxxxxxxxxxx.com
Date: 29 Apr 2009 15:29:16 -0600
Subject: xxxx Account Update
Content-Type: text/html; charset=utf-8
Content-Transfer-Encoding: base64
Return-Path: xxxxxx#xxxxxxxx.com
X-OriginalArrivalTime: 29 Apr 2009 21:29:16.0374 (UTC) FILETIME=[8C63AF60:01C9C911]
Pay close attention to the Content-Type and Content-Transfer-Encoding headers.
I believe the IMAP is over SSL, so it might be the connection to IMAP that gets out of sync. The best solution I have for that is just check to see if the body contains a really long word. Since that garble has no spaces:
<?php
function wordlength($txt, $limit)
{
$words = explode(' ', $txt);
foreach($words as $v)
{
if(strlen($v) > $limit)
{
return false;
}
}
return true;
}
?>
Usage:
<?php
$txt = "Message Body would be here";
if(!wordlength($txt, 45))
{
//maybe try to pull the message again or
//send an email to you telling you there is a problem
}
?>
I picked 45 just in case some uses the word Pneumonoultramicroscopicsilicovolcanoconiosis in an email. :D
Jordan might be right though. It may just be base64 encoded. I would just explode() the headers then and search for that and if it's there, a simple base64_decode() will do the trick.
This helped me with a garbled e-mail subject.
http://php.net/manual/en/function.imap-header.php
Related
I have written php code for reading email. I am using
imap_fetchbody($this->conn, $i, 1.2);
for displaying email message. When mail is with attachment it is display in well mannered but if email is without attachment it displays nothing. When I am using
$body = imap_fetchbody($this->conn, $i, 1);
message is displaying in text/plain format. like this
this is system generated mail -- Regards! Md Belal
When I am using
$body = imap_body($this->conn, $i);
it is displaying like this
--047d7b5d2f88ddb36c050069a175 Content-Type: text/plain; charset=UTF-8 this is system generated mail -- Regards! Md Belal 8287326270 --047d7b5d2f88ddb36c050069a175 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
this is system generated mail
--
Regards!
Md Belal
--047d7b5d2f88ddb36c050069a175--
I need to display it in well mannered. Like this.
this is system generated mail
--
Regards!
Md Belal
What to do please help. Thanks!
Try this
https://stackoverflow.com/a/14936048/2289510
btw i haven't tried but nl2br (http://hu1.php.net/nl2br) may can help you too, its adding line breaks when your result is in text/plain format and its contains \n \r characters.
I have a strange problem.
I am using PEAR SMTP on Ubuntu. When I send this message:
--==Alternative_Boundary_x{da5ccf044317613d9f8e371455f292a6}x
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
hello world - plain text test
--==Alternative_Boundary_x{da5ccf044317613d9f8e371455f292a6}x
Content-Type: text/html; charset="utf-8"
Content-Transfer-Encoding: 7bit
<i>hello world - html test</i>
--==Alternative_Boundary_x{da5ccf044317613d9f8e371455f292a6}x--
--==Mixed_Boundary_x{e46253d4aad6aff75d74ef5eb064a626}x
Content-Type: application/rtf; name="attachment.rtf"
Content-Disposition: attachment; filename="attachment.rtf"
Content-Transfer-Encoding: base64
e1xydGYxXGFuc2lcZGVmZjB7XGZvbnR0Ymx7XGYwXGZtb2Rlcm5cZnBycTFcZmNoYXJzZXQwIENv
dXJpZXIgTmV3O317XGYxXGZuaWxcZmNoYXJzZXQwIENvdXJpZXIgTmV3O319DQp7XGNvbG9ydGJs
IDtccmVkMFxncmVlbjBcYmx1ZTA7fQ0Ke1wqXGdlbmVyYXRvciBNc2Z0ZWRpdCA1LjQxLjE1LjE1
MTU7fVx2aWV3a2luZDRcdWMxXHBhcmRcY2YxXGxhbmcyMDU3XGYwXGZzMzIgSGVsbG8gd29ybGRc
Y2YwXGYxXGZzMjBccGFyDQpcY2YxXGlcZjBcZnMyNCBIZWxsbyB3b3JsZFxjZjBcaTBcZjFcZnMy
MFxwYXINClxiIEhlbGxvIHdvcmxkXHBhcg0KXGIwXHBhcg0KXHBhcg0KfQ0KAA==
--==Mixed_Boundary_x{e46253d4aad6aff75d74ef5eb064a626}x
--==Mixed_Boundary_x{e46253d4aad6aff75d74ef5eb064a626}x
Content-Type: text/xml; name="attachment.xml"
Content-Disposition: attachment; filename="attachment.xml"
Content-Transfer-Encoding: base64
PD94bWwgdmVyc2lvbj0iMS4wIj8+DQo8YXR0YWNoZW1udD5pbiAueG1sIGZpbGU8L2F0dGFjaGVt
bnQ+IA==
--==Mixed_Boundary_x{e46253d4aad6aff75d74ef5eb064a626}x--
I receive it without one of the --==Mixed_Boundary_x{e46253d4aad6aff75d74ef5eb064a626}x (look where there are two in a row) missing. Some how PEAR smtp send sends the message with that missing.
But if I do it from Windows, using phplib, it sends just fine and causes the attachments to work!
I know I could use the PEAR Mime mail to deal with this, but unfortunately, I am working with legacy code and that is not an option since the message has already had all the encodings.
My question is, why does PEAR remove it? And what does it break the attachments when not there?
Thanks
I can only assume from what you give, but the Ascii-Art in your boundary is really nice, but just probably a little over the top. It contains characters that are not allowed there per the specs, and that are the curly brackets. Maybe because of having an invalid email there, things get dropped?
Got it working! Turns out the extra line was not supposed to be there at all and was causing all sorts of problems.
Managed to change some code so that it was not there and it all started working!
I'm having trouble with a sendmail command.
I'm pulling the values out of a database call, and they look good.
The mail command looks like this:
sendmail(urldecode($row['tracker']),urldecode($row['recipient']),urldecode($row['docurl']),urldecode($row['last_accessed']));
function sendmail($vtracker,$vrecip,$vrawurl,$viewed){
$to = $vtracker;
$subject = $vrecip . " has viewed the presentation you sent them.</br>";
$body= "Full document url: " . $vrawurl . "<br/>".
"Time and Date Viewed: :" .$viewed ;
if (!mail($to, $subject, $body)) {
echo("<p>Message delivery failed...</p>");
}
}
I echoed all the variables and they look ok:
$vtracker: Bob ;
$vrecip : gregmcg#yahoo.com ;
$vrawurl : https://docs.google.com/a/advetel.com/present/edit?id=0Ac_KwUsBMiw8ZGN2Z3N3cDlfMTc3c2Jubng0Z2Q ;
$viewed : Mon, 20 Feb 2012 10:36:22 CST ;
I'm getting an error (retrieved from the error log on the server) that looks like this.
[error] [client 66.249.68.23] File does not exist: /var/chroot/home/content/m/3/s/m3sglobal/html/broadband/missing.html
[Tue Feb 21 20:17:15 2012] [error] [client 70.113.8.83] Failed loading /usr/local/zo/4_3/ZendOptimizer.so: /usr/local/zo/4_3/ZendOptimizer.so: undefined symbol: empty_string
[Tue Feb 21 20:17:17 2012] [error] [client 70.113.8.83] malformed header from script. Bad header=/home/content/m/3/s/m3sglobal/: Nitrofill_Presentation.php
Why is the header "malformed"?
I think it wouldn't hurt to spend a bit more time with RFC 2822.
Your to field is populated with Bob. That it not a legal address. The format of valid email addresses is quite complicated but these days, addresses generally are of the form localpart#domain. (Older formats that allowed delivery to UUCP addresses via % username specifiers or ! bang-paths are often not supported; further, username#[<ip address>] may or may not be supported on different servers or configurations. In general, there must be an # in an email address to separate the local part from the domain.)
You also appear to be using user-supplied data without any confirmation that it isn't performing header injection attacks. (See also the suhosin project's documentation about suhosin.mail.protect.)
Your subject field includes a </br>, which is pointless, since the Subject: header is interpreted as plain text. This field also appears to be using raw data supplied by the database.
The message body also includes the </br>, which is pointless, since your message does not include any MIME markup to indicate the presence of text/html content.
I'm trying to generate EML files from PHP. Is there any library that will allow me to easily create them? I could find some ActiveX component on the internet but would rather use something more portable.
I ended up building the MIME message myself using this kind of template, where each field is replaced by a TEMPLATE_<name> variable:
From: TEMPLATE_FROM_ADDRESS
MIME-Version: 1.0
To: TEMPLATE_TO_ADDRESS
Subject: TEMPLATE_SUBJECT
Content-Type: multipart/mixed; boundary="080107000800000609090108"
This is a message with multiple parts in MIME format.
--080107000800000609090108
Content-Type: text/plain
TEMPLATE_BODY
--080107000800000609090108
Content-Type: application/octet-stream;name="TEMPLATE_ATTACH_FILENAME"
Content-Transfer-Encoding: base64
Content-Disposition: attachment;filename="TEMPLATE_ATTACH_FILENAME"
TEMPLATE_ATTACH_CONTENT
--080107000800000609090108
Then creating the final message is quite simple using str_replace:
$content = file_get_contents("Template.eml");
$content = str_replace("TEMPLATE_FROM_ADDRESS", $fromEmail, $content);
$content = str_replace("TEMPLATE_TO_ADDRESS", $toEmail, $content);
// etc. for each template parameter
// Also don't forget to base64_encode the attachment content;
$content = str_replace("TEMPLATE_ATTACH_CONTENT", base64_encode($attachContent), $content);
Additional info about file attachment in this post: Attachment name and file extension not working in email *.eml
Edit (2018): Since this answer was written it seems it's been copied and pasted a bit everywhere, the template in particular. To avoid any conflict with other MIME data, you should make sure that the boundary "080107000800000609090108" is unique - it's a string of random characters no longer than 70 characters.
I think you don't need a library. It's just plain text (e.g. http://bitdaddys.com/example1.eml)
Date: Sat, 12 Aug 2006 14:25:25 -0400
From: John Doe <jdoes#someserver.com>
Subject: BitDaddys Software
To: sales#bitdaddys.com
Dear BitDaddys Corp.,
We have added your software to our approved list.
Thank you for your efforts.
Sincerely,
John Doe
Some Server Company
You can just output text with headers and save it using fwrite. For attachments use base64_encode() as stated here
Use imap_savebody (part of the imap library http://us1.php.net/manual/en/function.imap-savebody.php) with a null $part_number. It creates a beautiful .eml file with one line of code with the entire message (null $part_number = all parts... not documented but works).
the other two solutions depend on the format of the email (only one attachment and no html section in the first solution, and only text email in the second).
imap_savebody creates a perfect .eml file no matter what the format of the incoming email is (as long as it's RFC-complaint of course).
I am parsing emails with Zend_Mail, and strangely some content gets truncated without an obvious reason and malforms the email parts.
For example
Content-Disposition: attachment; filename="file.sdv"
DQogICAgICBTT05FO0xBTkRJTkdTREE7U0FMR1NEQVRPIDtOQVNKIDtSRURTS0FQICAgICAgICAg
ICAgIDsgRklTS0VTTEFHO1BSRVNFUlYgICA7ICBUSUxTVEFORDsgU1TYUlJFTFNFOyAgS1ZBTElU
RVQ7T01TVFlQRSAgO01JTlNURVBSSVM7ICAgICBWRVJESTsgICBLVkFOVFVNOyAgUlVORFZFS1Qg
IA0KLS0tLS0tLS0tLTstLS0tLS0tLS0tOy0tLS0tLS0tLS07LS0tLS07LS0tLS0tLS0tLS0tLS0t
LS0tLS07LS0tLS0tLS0tLTstLS0tLS0tLS0tOy0tLS0tLS0tLS07LS0tLS0tLS0tLTstLS0tLS0t
LS0tOy0tLS0tLS0tLTstLS0tLS0tLS0tOy0tLS0tLS0tLS07LS0tLS0tLS0tLTstLS0tLS0tLS0t
ICANCiAgICAgICAgIDA7MjAxMC4wOS4wODsyMDEwLjA5LjA4O05vcnNrO0dhcm4gICAgICAgICAg
ICAgICAgOyAgICAgIDEwMjE7RkVSU0sgICAgIDsgICAgICAgMjEwOyAgIDQwMjA5OTk7ICAgICAg
ICAyMDtFZ2Vub3ZlcnQ7ICAgICAgICAgIDsgICAzMDcyLDE2OyAgICAgICAyMTE7ICAgICAyNTMs
MiAgDQogICAgICAgICAwOzIwMTAuMDkuMDg7MjAxMC4wOS4wODtOb3JzaztHYXJuICAgICAgICAg
Gets truncated to
Content-Disposition: attachment; filename="file.sdv"
DQogICAgICBTT05FO0xBTkRJTkdTREE7U0FMR1NEQVRPIDtOQVNKIDtSRURTS0FQICAgICAgICAg
ICAgIDsgRklTS0VTTEFHO1BSRVNFUlYgICA7ICBUSUxTVEFORDsgU1TYUlJFTFNFOyAgS1ZBTElU
RVQ7T01TVFlQRSAgO01JTlNURVBSSVM7ICAgICBWRVJESTsgICBLVkFOVFVNOyAgUlVORFZFS1Qg
IA0KLS0tLS0tLS0tLTstLS0tLS0tLS0tOy0tLS0tLS0tLS07LS0tLS07LS0tLS0tLS0tLS0tLS0t
LS0tLS07LS0tLS0tLS0tLTstLS0tLS0tLS0tOy0tLS0tLS0tLS07LS0tLS0tLS0tLTstLS0tLS0t
LS
a var_dump on each line shows this.
string(78) "DQogICAgICBTT05FO0xBTkRJTkdTREE7U0FMR1NEQVRPIDtOQVNKIDtSRURTS0FQICAgICAgICAg
"
string(78) "ICAgIDsgRklTS0VTTEFHO1BSRVNFUlYgICA7ICBUSUxTVEFORDsgU1TYUlJFTFNFOyAgS1ZBTElU
"
string(78) "RVQ7T01TVFlQRSAgO01JTlNURVBSSVM7ICAgICBWRVJESTsgICBLVkFOVFVNOyAgUlVORFZFS1Qg
"
string(78) "IA0KLS0tLS0tLS0tLTstLS0tLS0tLS0tOy0tLS0tLS0tLS07LS0tLS07LS0tLS0tLS0tLS0tLS0t
"
string(78) "LS0tLS07LS0tLS0tLS0tLTstLS0tLS0tLS0tOy0tLS0tLS0tLS07LS0tLS0tLS0tLTstLS0tLS0t
"
string(5) "LS)
"
string(17) "TAG5 OK Success
"
or in other email at
DQogICAgICBTT05FO0xBTkRJTkdTREE7U0FMR1NEQVRPIDtOQVNKIDtSRURTS0FQICAgICAgICAg
ICAgIDsgRklTS0VTTEFHO1BSRVNFUlYgICA7ICBUSUxTVEFORDsgU1TYUlJFTFNFOyAgS1ZBTElU
RVQ7T01TVFlQRSAgO01JTlNURVBSSVM7ICAgICBWRVJESTsgICBLVkFOVFVNOyAgUlVORFZFS1Qg
IA0KLS0tLS0tLS0tLTstLS0tLS0tLS0tOy0tLS0tLS0tLS07LS0tLS07LS0tLS0tLS0tLS0tLS0t
LS0tLS07LS0tLS0tLS0tLTstLS0tLS0tLS0tOy0tLS0tLS0tLS07LS0tLS0tLS0tLTstLS0tLS0t
LS0tOy0tLS0tLS0tLTstLS0tLS0tLS0tO
I cannot figure out why is stopping there. The transmitions should have stoped at the end of the line only. This is the line that gets the string from the IMAP Server.
$line = #fgets($this->_socket);
The encoded text contains a string like, but again this is truncated in various parts in different emails.
----------;----------;----------;-----;--------------------;----------;----------;--
I've tried to add a size to fgets() but to no results.
I also enabled/disabled "auto_detect_line_endings" php_ini setting, again to no result.
I've also opened a bug report with ZF although the error does not seem to be in the library.
Do you see anything strange with this encoded string?
UPDATE
New research shows that the emails get truncated after 584 chars. Still don't know why.
Sent a question to google as well. See here.
A Bad email headers :
Delivered-To: email#removed.com
Received: by 10.216.3.208 with SMTP id 58cs248812weh;
Fri, 20 Nov 2009 05:14:14 -0800 (PST)
Received: by 10.204.153.217 with SMTP id l25mr1285471bkw.108.1258722853863;
Fri, 20 Nov 2009 05:14:13 -0800 (PST)
Return-Path: <>
Received: from MTX4.mbn1.net (mtx4.mbn1.net [213.188.129.252])
by mx.google.com with SMTP id 2si1800716bwz.60.2009.11.20.05.14.12;
Fri, 20 Nov 2009 05:14:13 -0800 (PST)
Received-SPF: pass (google.com: best guess record for domain of MTX4.mbn1.net designates 213.188.129.252 as permitted sender) client-ip=213.188.129.252;
Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of MTX4.mbn1.net designates 213.188.129.252 as permitted sender) smtp.mail=
Resent-From: <email#removed.com>
Content-Type: multipart/mixed; boundary="===============1703099044=="
MIME-Version: 1.0
From: <email#removed.com>
To: <email#removed.com>
CC:
Subject: some subject
Message-ID: <FLYNDRElQ080Gxw8Zw500000f46email#removed.com>
X-OriginalArrivalTime: 20 Nov 2009 13:14:08.0121 (UTC) FILETIME=[5792C690:01CA69E3]
Date: Fri, 20 Nov 2009 14:14:08 +0100
X-STA-Metric: 0 (engine=030)
X-STA-NotSpam: tlf: vedlagt skip:__ 40 fil cc:2**0
X-STA-Spam: header:MIME-Version: charset:us-ascii header:Subject:1 to:2**0 header:From:1
X-BTI-AntiSpam: score:0,sta:0/030,dnsbl:passed,sw:off,bsn:38/passed,spf:off,bsctr:passed/1,dk:off,pbmf:none,ipr:0/3,trusted:no,ts:no,bs:no,ubl:passed
X-Auto-Response-Suppress: DR, RN, NRN, OOF, AutoReply
Resent-Message-Id: <19740416124736.CF5804B33EF632B0email#removed.com>
Resent-Date: Fri, 20 Nov 2009 14:14:11 +0100 (CET)
--===============1703099044==
Content-Type: application/octet-stream
MIME-Version: 1.0
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="file.sdv"
DQpHUlVQUEVOQVZOICAgICAgICAgIDtLSthQRTtQUk9EQU5MO1BBS0tFTlI7TU9UVEFLTkFWTiAg
ICAgICAgICAgICAgICAgICAgO1NPTjtMQU5ESU5HU0RBO1NBTEdTREFUTyA7TkFTSiA7UkVEU0tB
UCAgIDtGSVNLRVNMQUcgO1BSRVNFUlYgICA7VElMU1RBTkQ7U1TYUlJFTFM7S1ZBTElURVQ7TUlO
U1RFUFJJUzsgICAgICAgIFZFUkRJOyAgICAgS1ZBTlRVTTsgICAgUlVORFZFS1QgICAgDQotLS0t
LS0tLS0tLS0tLS0tLS0tLTstLS0tLTstLS0tLS0tOy0tLS0tLS07LS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tOy0tLTstLS0tLS0tLS0tOy0tLS0tLS0tLS07LS0tLS07LS0tLS0tLS0tLTst
LS0tLS0tLS0tOy0tLS0tLS0tLS07LS0tLS0tLS07LS0tLS0tLS07LS0tLS0tLS07LS0tLS0tLS0t
LTstLS0tLS0tLS0tLS0tOy0tLS0tLS0tLS0tLTstLS0tLS0tLS0tLS0gICAgDQpMb3JlbnR6ZW4g
....
For those interested in an answer and not in the (ex) bounty, more clues.
Gmail is returning a short value in response to RFC822.SIZE, which can lead to truncated messages. (They are off by one byte for each header line, apparently not counting two characters for CR/LF.)
I think you're looking in the wrong place.
The imap server gives you the mail message truncated, and then returns its status line TAG5 OK Success.
I don't see how your (/php's) handling of the socket would make a few kb worth of stream disappear, to magically fix the stream right before this status line.
So either the message is truncated by itself (have you verified the message contents through some other way?) or the imap server is just broken.
The first things I would do, are:
find a sufficiently silent environment to put your project, where you can strace -f -s 10240 -p <pid> apache's process to verify the socket interaction (assuming a linux/apache environment)
and/or: use tcpdump, ethereal or equivalent to check what's coming in on the line
My guess is that you will see the exact same truncated strings coming in on the wire. Meaning you can shift your focus to the imap server.
Reassuring yourself that you're looking in the right place can save a lot of time.
1: try removing the # for more verbosity
2: try using http://www.php.net/manual/en/function.fread.php instead of fgets
This might have something to do with the IMAP server, because i see TAG5 OK Success as a response, even if its not supposed to be there.
Have you tried issuing another fgets and see if you get the rest of the data? You may be retrieving a multi-part email which would require multiple requests.
But regardless, you are using functions designed for file access on a network. Usually this works fine, but depending on the network, issues can arise. For example, you can use file_get_contents to retrieve a web page. But if the issue issues a redirect, then it fails. But using curl will be much more successfully.
If you truly want to read the network socket, you should try socket_read. That is designed with the network in mind, like curl.
Do not know Zend and forgot all about PHP but played with MIME and HTTP before (C++).
I suggest you start looking at finding way to add a Content-Length header entry. It gives a hint to the "message decoder/loader" to expect a certain size in the content (message payload). (Not sure if IMAP does that)
In the code above I would try to convince fgets to read a specific amount of expected data from the network. It could be that the data is buffered or not yet sent over the network (async communication) and fgets only reads an internal buffer thus stopping before the whole message was read.
To see if this is the case, send a small message that falls under your "584 breaking point".
Do some network tracing the see if all the data actually flows. (You would probably need to do some local setup)
The code you are referring to is here?
Most likely one of your server hardware is compromised and thus you want to change it completely or just change the RAM modules or Disk-Drives. I've some experience with Web-and-Mail based encoding and I can confirm you that base64 encoded string is very secure. At least it uses a texture mapping algorithm.