I am writing a little Perl app to send emails internally where I work, but I am having troubles with attachments. Now, I can hear all of you screaming "use MIME::Lite", but it aint that easy - management rules tell me I am unable to use anything from the cpan...
Anyhow, I am using MIME::Base64 to encode any attachements I am sending. I am using Net::SMTP for the email side of things.
encoding is done as such (straight out of the Perldoc page):
my $encoded = "";
use MIME::Base64 qw(encode_base64);
open (FILE, "7857084216_9816ae9bec_b.jpg") or die "$!\n";
while (read(FILE, $buf, 60*57)) {
$encoded .= encode_base64($buf);
}
The relevant Net::SMTP code is as follows:
use Net::SMTP;
$smtp = Net::SMTP->new("mailserver",
Hello => 'somedomain.com.au',
Timeout => 60,
Debug => 0,
);
$smtp->mail(<services\#somedomain.com.au>);
$smtp->to(<me\#somedomain.com.au>);
$smtp->cc(<another\#somedomain.com.au>);
$smtp->data();
$smtp->datasend("Subject: testing 123\n");
$smtp->datasend("To: me\#somedomain.com.au\n");
$smtp->datasend("CC: another\#somedomain.com.au\n");
$smtp->datasend("MIME-Version: 1.0\n");
$smtp->datasend("Content-type: multipart/mixed;\n\tboundary=\"$boundary\"\n");
$smtp->datasend("--$boundary\n");
$smtp->datasend("Content-type: text/html; charset=utf-8\n");
$smtp->datasend("\n");
$smtp->datasend("<p> Test Email!</p>\n");
$smtp->datasend("\n");
$smtp->datasend("--$boundary\n");
$smtp->datasend("Content-type: image/jpeg; name=\"7857084216_9816ae9bec_b.jpg\"\n");
$smtp->datasend("Content-ID: \n");
$smtp->datasend("Content-Disposition: attachment; filename=\"7857084216_9816ae9bec_b.jpg\"\n");
$smtp->datasend("Content-transfer-encoding: base64\n");
$smtp->datasend("\n");
$smtp->datasend("$encoded");
$smtp->datasend("\n");
$smtp->datasend("--$boundary--\n");
$smtp->dataend;
$smtp->quit;
At this moment, I am directing these emails through to myself and reading them using Outlook 2010
When sending images (such as jpegs), I am not having any issues at all - everything seems to decode OK byte for byte as far as I can see.
When I am sending docx type files with just plain text, everything seems fine.
But, when I am sending docx files with images inserted, the files are corrupting.
Not being an expert in mail sending and attaching, I am at a bit of a loss. How should I be encoding docx files for attaching to emails? Any help would be appreciated!
Also forgot to mention, I have attempted to set the content-type accordingly: Content-type: application/vnd.openxmlformats-officedocument.wordprocessingml.document
I've seen this happen before and usually comes down to just the incorrect mime type or mime structure. You mention you tried adding the mime type, so that might indicate that the mime structure might be a little off. I've seen this with xslx and csv files. CSV would come in find since the decoder assumes text, but if you don't have the right Mime for binary data it will always attempt to convert to ascii. I realize this around an xslx vs docx, but I think the same principles apply.
Here is a snip of an sample email I'm generating (Using Mime:Lite), but might help.
From: me#example.com
To: example#example.com
Subject: Example
Content-Transfer-Encoding: binary
Content-Type: multipart/mixed; boundary="_----------=_13433203262384120"
--_----------=_13433203262384120
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html
Content-Disposition: inline
<body>Hello,<br>
<p>EMAIL BODY</p>
<p>Thanks,<br> Blah</body>
--_----------=_13433203262384120
Content-Type: application/vnd.openxmlformats-officedocument.spreadsheetml.sheet; name="sample.xlsx"
Content-Disposition: attachment; filename="sample.xlsx"
Content-Transfer-Encoding: base64
UEsDBBQAAAAIAAFk+kDm/EEvVgEAACQFAAATAAAAW0NvbnRlbnRfVHlwZXNdLnhtbMVUS28CIRC+
N+l/IFybXdRD0zSuHvo4tia1P4DC6BJZIAxa/fed3a32EesjmvQCgfleQ8j0h8vKsgVENN4VvJt3
OAOnvDZuWvDX8WN2wxkm6bS03kHBV4B8OLi86I9XAZAR22HBy5TCrRCoSqgk5j6Ao8rEx0omOsap
CFLN5BREr9O5Fsq7BC5lqdbgg/49TOTcJvawpOs2SQSLnN21wNqr4DIEa5RMVBcLp3+5ZJ8OOTEb
DJYm4BUBOBNbLZrSnw5r4jM9TjQa2EjG9CQrggnt1Sj6gIII+W6ZLUH9ZGIUkMa8IkoOdSINOgsk
CTEZ+Eq901z5CMe7r5+pZh9qubQC08oCntwshghSYwmQKpu3ovusE30qaNfuyQEamX2O7z7O3ryf
.... <Snipped>
ZRQyppbEwDToT079O3NfFSgofVlmcbvM34PqkQQdCmrLiWYxleokviz25OPYvpRw/s64avTwn+uh
SSg4ctedMMaTkj47g3IXX1BLAQIUAxQAAAAIAAFk+kDm/EEvVgEAACQFAAATAAAAAAAAAAEAAAC2
gQAAAABbQ29udGVudF9UeXBlc10ueG1sUEsBAhQDFAAAAAgAAWT6QPWzn3yRAQAAQAMAABAAAAAA
AAAAAQAAALaBhwEAAGRvY1Byb3BzL2FwcC54bWxQSwECFAMUAAAACAABZPpAkg6xSFoBAAC2AgAA
EQAAAAAAAAABAAAAtoFGAwAAZG9jUHJvcHMvY29yZS54bWxQSwECFAMUAAAACAABZPpAyfySzFpy
BAAcqRgAFAAAAAAAAAABAAAAtoHPBAAAeGwvc2hhcmVkU3RyaW5ncy54bWxQSwECFAMUAAAACAAB
ZPpARQtWMQgCAABaBQAADQAAAAAAAAABAAAAtoFbdwQAeGwvc3R5bGVzLnhtbFBLAQIUAxQAAAAI
AABk+kCVKtbcsAEAAFgDAAAPAAAAAAAAAAEAAAC2gY55BAB4bC93b3JrYm9vay54bWxQSwECFAMU
AAAACAABZPpA8XOrpLUFAABVGwAAEwAAAAAAAAABAAAAtoFrewQAeGwvdGhlbWUvdGhlbWUxLnht
bFBLAQIUAxQAAAAIAO1j+kD+7E73UA8AAM1zAAAYAAAAAAAAAAEAAAC2gVGBBAB4bC93b3Jrc2hl
ZXRzL3NoZWV0MS54bWxQSwECFAMUAAAACAAAZPpA7/olcLO/MgAHxsABGAAAAAAAAAABAAAAtoHX
kAQAeGwvd29ya3NoZWV0cy9zaGVldDIueG1sUEsBAhQDFAAAAAgAAWT6QCFo34b0AAAATgMAABoA
AAAAAAAAAQAAALaBwFA3AHhsL19yZWxzL3dvcmtib29rLnhtbC5yZWxzUEsBAhQDFAAAAAgAAWT6
QIB6g4TsAAAAUQIAAAsAAAAAAAAAAQAAALaB7FE3AF9yZWxzLy5yZWxzUEsFBgAAAAALAAsAxgIA
AAFTNwAAAA==
--_----------=_13433203262384120--
I have found the issue and it does appear that the 'content-type' does seem to make a difference. According to what I found, I replaced all the Content-type calls, that include Base64 encoded data with the following:
Content-type: application/octet-stream;
This seemed to have sent it straight through, no issues with either Outlook 2010 and 2003. I have tested it against binary files, plain text, ect and all seems to work OK in my current environment.
Cheers
Related
I would like to send message from Unix server. I use command 'mail':
echo "MESSAGE_BODY" | mail -s "MESSAGE_TITLE" somebody#gmail.com
It's ok with it.
After that I want to send message with different colors. I tried this command:
echo "<font color="red">MESSAGE_BODY</font>" | mail -s "MESSAGE_TITLE" somebody#gmail.com
But it didn't help me. How to use colors ?
There have already been a "one-liner" that have posted the correct answer.
I do still feel that it's better to post how and why.
The reason why you can't just echo HTML code directly into your mail is that the receiver (Client) don't know how to display it. So it will most likely just fallback to clear text and all you would see was your HTML code when viewing the message.
What you need, is to tell the client that the content of your message is composed in HTML. You do this by adding the correct MIME header to the message.
Content-Type: text/html; charset=UTF-8
MIME-Version: 1.0
Notice you can also set charset information.
The MIME version is there for better compatibility also some SMTP servers will give you a higher spam score if you don't obey the RFC :)
But with these headers set now all "BODY" content will be treated like HTML content.
I don't just want to provide you with a "one-liner" I think showing more in a script is better to make it easier to read.
So how about this
(
echo "From: my#email.tld";
echo "To: some#email.tld";
echo "Subject: Test html mail";
echo "Content-Type: text/html";
echo "MIME-Version: 1.0";
echo "";
echo "<strong>Testing</strong><br><font color=\"blue\">I'm Blue :)</font>";
) | sendmail -t
Well technically it's still a one-liner :) But it just looks nicer and you can see what's going on!
Bonus information
If you want to have both HTML and TEXT bodies you need to look into Multipart content type bodies. I have included an example but you would properly need to read up on this if you don't know much about multipart types.
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="--0001boundary text--"
--0001boundary text--
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable
The TEXT body goes here
--0001boundary text--
Content-Type: text/html; charset="utf-8"
Content-Transfer-Encoding: quoted-printable
<strong>HTML code goes here</strong>
--0001boundary text--
As you can see it's no longer some simple mail body.
But I thought I wanted to show you how it was done in case you wanted to give it a go.
echo "<font color="green">Message body</font>" | mail -s "$(echo -e "Message title\nContent-Type: text/html")" somebody#gmail.com
I'm using perl's Mail::Sendmail to send email notifications, but I'm having trouble displaying Japanese. Mail::Sendmail changes the Japanese to html numeric character references, but one email client I use (claws mail) doesn't display those in html mode, while none do in text mode. Mail::Sendmail also changes newlines to <br>. I want neither. What am I doing wrong? I use basic options, like these for plain text:
my %mail = (smtp => 'localhost:25',
to => $to,
from => $from,
'content-type' => 'text/plain; charset=UTF-8',
subject => $subject,
message => $text);
sendmail(%mail) or warn $Mail::Sendmail::error;
output is like:
....
Subject: test
Date: Fri, 19 Dec 2014 14:59:31 +0100
Mime-Version: 1.0
Content-Type: text/plain; charset=UTF-8
To: me#foo.com
Content-Transfer-Encoding: quoted-printable
From: info#foo.com
....
content: test this: 怖い <br>end test.=20
I would like to get rid of the numeric character references and html, how do I do that?
To answer my own question: The assumption that Mail::Sendmail was adding the entities was wrong. I should have checked the other code of the program I was working on more thoroughly.
i send a mail from a monitoring system to another linux box that handles and parses the mail. The mail is sent with the following headers:
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: quoted-printable
the problem is that the last line of the mail gets split and a = sign gets added:
CRIT - 93.2% used (466.06 of 500.0 GB), (levels at 80.00/90.00%), trend=
: +5.66MB / 24 hours=
do you have any idea how can i prevent that quote-printable problem so that the last line on the mail is not altered by the receiving MUA.
thank you
Mario.
quoted-printable does this by design, special characters are replaced
such that \r\l or \n are encoded.
The email client sees the mime-header
Content-Transfer-Encoding: quoted-printable
and reverses that to get back the original formatting.
Set out to write a simple procmail recipie that would forward the mail to me if it found the text "Unprovisioned" in the subject.
:0:
* ^Subject:.*Unprovisioned.*
! me#test.com
Unfortunately the subject field in the mail message coming from the mail server was in MIME encoded-word syntax.
The form is: "=?charset?encoding?encoded text?=".
Subject: =?UTF-8?B?QURWSVNPUlk6IEJNRFMgMTg0NSwgTkVXIFlPUksgLSBVbnByb3Zpc2lvbmVkIENvbm4gQQ==?=
=?UTF-8?B?bGVydA==?=
The above subject is utf-8 charset, base64 encoding with text folded to two lines. So was wondering if there are any mechanisms/scripts/utilities to parse this and convert to string format so that I could apply my procmail filter. Ofcourse I can write a perl script to parse this an perform the required validations, but looking to avoid it if possible.
Encode::MIME::Header, which ships with Perl, accessed directly through Encode:
use Encode qw(encode decode);
my $header_text = decode('MIME-Header', $header);
I use MIME::Entity module in Perl to create a MIME message. Some of the headers seem to be encoded OK, while other seem to have issues with folding.
Code:
use strict;
use Encode;
use MIME::Entity;
my %build_params = (
'Charset' => 'UTF-8',
'From' => encode('MIME-Header', 'Fantasy Email <vujerldujhgurtelhwgutrwhgunwlhvulhgvnuwlhvuwlnhvgnulwh#gmail.com>'),
'Subject' => encode('MIME-Header', "A very long subject that will span on multiple lines in the headers, with a leading sp\
ace at the beginning of each new line."),
'Type' => 'multipart/alternative',
);
my $top = MIME::Entity->build(%build_params);
$top->print_header();
Output:
Content-Type: multipart/alternative;
boundary="----------=_1312196104-11708-0";
charset="UTF-8"
Content-Transfer-Encoding: binary
MIME-Version: 1.0
X-Mailer: MIME-tools 5.427 (Entity 5.427)
Subject: A very long subject that will span on multiple lines in the
headers, with a leading space at the beginning of each new line.
From: Fantasy Email
<vujerldujhgurtelhwgutrwhgunwlhvulhgvnuwlhvuwlnhvgnulwh#gmail .com>
The Subject seems to be correctly split into multiple lines. The From doesn't, leaving a space before the com, but the newline is gone.
Is this standard behavior or have I found a bug in MIME::Entity?
Encode::MIME::Header (called as encode('MIME-Header', ...)) does some line splitting (called folding in the RFC 822).
Unfortunately, MIME::Entity does some line splitting too, probably in a different way. It also gets rid of the newline generated by Encode::MIME::Header. It leaves the spaces though.
I would be happy to leave MIME::Entity deal with the encoding of my headers, but it looks like it just does the line splitting part. So I guess I still have to encode them myself.
As a workaround, I removed the line splitting markers from my encoded headers with
my $encoded_from = encode('MIME-Header', 'Fantasy Email <vujerldujhgurtelhwgutrwhgunwlhvulhgvnuwlhvuwlnhvgnulwh#gmail.com>');
$encoded_from =~ s/\r?\n\s//g;
(And same thing for the subject.)
Now the output looks like this:
Subject: A very long subject that will span on multiple lines in the
headers, with a leading space at the beginning of each new line.
From: Fantasy Email
<vujerldujhgurtelhwgutrwhgunwlhvulhgvnuwlhvuwlnhvgnulwh#gmail.com>
I'm wondering if there's a more elegant solution, like Encode::MIME::Header featuring a MIME::Entity compatibility mode or something like that.