imap server fetch not working properly - email

I'm currently working on my own IMAP server.
When i get a FETCH request for 3 mails and i send a response with 3 mails, the client does not seem to recognise my response. (my client reports that there is no mail)
This is the request and response (C is client, S is server):
C: 405 UID FETCH 4,3,1 (INTERNALDATE RFC822.SIZE FLAGS BODY.PEEK[HEADER.FIELDS (subject from date content-type to cc message-id references importance reply-to)])
S: * 3 FETCH (UID 4 RFC822.SIZE 332 INTERNALDATE "<date>" FLAGS (\Recent) BODY[HEADER.FIELDS (SUBJECT FROM DATE CONTENT-TYPE TO CC MESSAGE-ID REFERENCES IMPORTANCE REPLY-TO)] {317}
Subject: <subject>
From: <email>
Date: <date>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
To: <email>
CC: <email>
Message-ID: <messid>
Reply-To: <email>
)
S: * 2 FETCH (UID 3 RFC822.SIZE 731 INTERNALDATE "<date>" FLAGS (\Recent) BODY[HEADER.FIELDS (SUBJECT FROM DATE CONTENT-TYPE TO CC MESSAGE-ID REFERENCES IMPORTANCE REPLY-TO)] {231}
Subject: <subject>
From: <email>
Date: <date>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Message-ID: <messid>
Reply-To: <email>
)
S: * 1 FETCH (UID 1 RFC822.SIZE 400 INTERNALDATE "<date>" FLAGS (\Answered \Recent) BODY[HEADER.FIELDS (SUBJECT FROM DATE CONTENT-TYPE TO CC MESSAGE-ID REFERENCES IMPORTANCE REPLY-TO)] {252}
Subject: <subject>
From: <email>
Date: <date>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
To: <email>
Message-ID: <messid>
Reply-To: <email>
)
S: 405 OK UID FETCH completed
where (subject) is the actual subject, (email) are valid emailadresses, (date) is the date and (messid) is a unique message-id.
Does somebody see what i am doing wrong here. maybe i am sending the wrong response, or am i doing something else wrong?
can someone help me with this?
so far, anything else (login, list, search) works fine. if it is needed, i could send those requests/responses as well
thanx i advance.

Related

How can I forward an email that contains a picture with smtplib?

My code only extracts text types in an email, and forwards the email.
My code:
msg=email.message_from_string(raw_email.decode('utf-8')) #raw_email = fetched[0][1]
content = ''
content_type = None
if msg.is_multipart():
for part in msg.walk():
if part.get_content_maintype() == 'text':
thispart = part.get_payload(decode=True)
if isinstance(thispart, bytes):
thispart = thispart.decode()
content = thispart
content_type = part.get_content_subtype()
else:
if msg.get_content_maintype() == 'text':
thispart = msg.get_payload()
if isinstance(thispart, bytes):
thispart = thispart.decode()
content = thispart
content_type = msg.get_content_subtype()
my_mail = email.message.EmailMessage()
my_mail.set_content(content)
But some emails contain pictures, so what I want more is to forward pictures also.
It comes like this:
Received: from [127.0.0.1] ()
by xxxx () with ESMTP id xxxx
for <xxx#xxx>; Wed, 27 May 2020 18:09:34 +0900
Content-Type: multipart/alternative;
boundary="--_NmP-ebdbfeeb1622aae7-Part_1"
X-FireEye: Clean
From: xxxx#xxxx
To: xxx#xxx
Subject: =?UTF-8?Q?XXXXX?=
Message-ID: <XXXXXX#XXX>
Date: Wed, 27 May 2020 09:09:34 +0000
MIME-Version: 1.0
----_NmP-ebdbfeeb1622aae7-Part_1
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
CONTENT Link </a><br>URL : <a =href></a><br><br><br>
----_NmP-ebdbfeeb1622aae7-Part_1
Content-Type: multipart/related; type="text/html";
boundary="--_NmP-ebdbfeeb1622aae7-Part_3"
----_NmP-ebdbfeeb1622aae7-Part_3
Content-Type: text/html; charset=utf-8
Content-Transfer-Encoding: quoted-printable
CONTENT Link </a><br>URL : <a =href></a><br><br><br> <img src=3D"cid:unique"/>
----_NmP-ebdbfeeb1622aae7-Part_3
Content-Type: image/png; name=image.png
Content-ID: <unique>
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename=image.png
LOTS_OF_WIERD_CHARACTERS
----_NmP-ebdbfeeb1622aae7-Part_3--
----_NmP-ebdbfeeb1622aae7-Part_1--
This mail is multiparted, and there are lots of weird characters which seem to represent an image.
How can I create a multipart email that contains an image, and how can I represent that image with the received weird characters??
Thanks:)

Outlook not rendering emails sent

I'm a bit baffled by this. It works fine in everything I've tested, except Outlook
my #all_parts;
push #all_parts, Email::MIME->create(
body_str => $text,
attributes => {
encoding => 'quoted-printable',
content_type => "text/plain",
disposition => "inline",
charset => "UTF-8"
}
);
my $email = Email::MIME->create(
header_str => [
From => $from,
To => [ $to ],
Subject => $subject
],
parts => \#all_parts,
attributes => {
content_type => "multipart/mixed"
}
);
print "Content-type: text/html \n\n";
print "<pre>" . $email->as_string . "</pre> ";
Which outputs this message:
From: delicia#x.com
To: andy.newby#hotmail.com
Subject: webform delicia Menu
Date: Sat, 21 Mar 2020 04:22:57 -0700
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="15847897770.621258BEF.22006"
Content-Transfer-Encoding: 7bit
--15847897770.621258BEF.22006
Date: Sat, 21 Mar 2020 04:22:57 -0700
MIME-Version: 1.0
Content-Type: text/plain; charset="UTF-8"
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable
foo bar=
--15847897770.621258BEF.22006--
For some reason it shows up buggered:
I must be missing something really stupid - but I can't see it. Maybe a missing header?
The full source of an incoming email looks like:
Return-path: <x#x.com>
Envelope-to: support#mysite.co.uk
Delivery-date: Sat, 21 Mar 2020 15:33:16 +0000
Received: from gt-van-cus5.nmsrv.com ([208.70.247.69])
by admin.foo.com with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256)
(Exim 4.86_2)
(envelope-from <x#x.com>)
id 1jFg7e-0006lZ-G5
for support#mysite.co.uk; Sat, 21 Mar 2020 15:33:16 +0000
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=x.com; h=message-id
:from:to:subject:date:mime-version:content-type
:content-transfer-encoding; s=mail; bh=TUrwl9pmlEV+CwP8vMMqxIQa9
Bg=; b=G2DuFVkwBF8qkCi7zM3hnwl18nkdIW83JbAoheLTAG9Xh6Ix2bxdPVsP7
3wI1cjUDjWGhTUlMLHGKP5kHT4FPKFkhMclIv+KZ1jU65BaMjRuwWz/FkTRg7v6I
oClvU/PXXn5gqfRiYZHR4L8qgCQaGhuXncxNgtaELqoQosU+gc=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=x.com; h=message-id
:from:to:subject:date:mime-version:content-type
:content-transfer-encoding; q=dns; s=mail; b=VHNvnP4AnMZxow+CoUj
3Xxj5KkIWJtUOJf21kf+E/vhvKWbbb7IEWHFNuQGATCAG+WX529rMQ83l9KsDB9d
G9gRo0Hsw7CK2D56wv7m22ur6QeaCgZNF7xHEECxZkaT9jlI9JFLU8pSXaFvSEcC
YgqKlm2b+zs0Q4mW8mH89xiQ=
Received: (qmail 23888 invoked by uid 1000); 21 Mar 2020 15:33:12 -0000
X-AntiVirus: Clean
Message-ID: <20200321153311.23887.qmail#gt-van-cus5.nmsrv.com>
From: x#x.com
To: support#mysite.co.uk
Subject: =?UTF-8?B?d2ViZm9ybSA=?=
Date: Sat, 21 Mar 2020 08:33:11 -0700
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="15848047911.6F3Ff.23881"
Content-Transfer-Encoding: 7bit
X-Spam-Score: 16
X-Spam-Bar: +
X-Spam-Report: Spam detection software, running on the system "admin.foo.com",
has NOT identified this incoming email as spam. The original
message has been attached to this so you can view it or label
similar future email. If you have any questions, see
##CONTACT_ADDRESS## for details.
Content preview: Date: Sat, 21 Mar 2020 08:33:11 -0700 MIME-Version: 1.0 Content-Type:
multipart/alternative; boundary="15848047910.05Ba9cd88.23881" [...]
Content analysis details: (1.6 points, 4.0 required)
pts rule name description
---- ---------------------- --------------------------------------------------
-0.0 SPF_HELO_PASS SPF: HELO matches SPF record
1.1 TRACKER_ID BODY: Incorporates a tracking ID number
0.0 T_TVD_MIME_NO_HEADERS BODY: No description available.
0.5 T_DKIM_INVALID DKIM-Signature header exists but is not valid
0.0 T_MIME_MALF Malformed MIME: headers in body
--15848047911.6F3Ff.23881
Date: Sat, 21 Mar 2020 08:33:11 -0700
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="15848047910.05Ba9cd88.23881"
Content-Transfer-Encoding: 7bit
--15848047910.05Ba9cd88.23881
Date: Sat, 21 Mar 2020 08:33:11 -0700
MIME-Version: 1.0
Content-Type: text/plain; charset="UTF-8"
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable
foo bar=
--15848047910.05Ba9cd88.23881
Date: Sat, 21 Mar 2020 08:33:11 -0700
MIME-Version: 1.0
Content-Type: text/html; charset="UTF-8"
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable
some message=
--15848047910.05Ba9cd88.23881--
--15848047911.6F3Ff.23881
Date: Sat, 21 Mar 2020 08:33:11 -0700
MIME-Version: 1.0
Content-Type: image/jpeg; name="logo.jpg"
Content-Disposition: attachment; filename="logo.jpg"
Content-Transfer-Encoding: base64
/9j/4AAQSkZJRgABAQEAYABgAAD/2wBDAAIBAQEBAQIBAQECAgICAgQDAgICAgUEBAMEBgUGBgYF
BgYGBwkIBgcJBwYGCAsICQoKCgoKBggLDAsKDAkKCgr/2wBDAQICAgICAgUDAwUKBwYHCgoKCgoK
CgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgr/wgARCAAlAPwDAREA
AhEBAxEB/8QAHAABAAMBAQEBAQAAAAAAAAAAAAUGBwgDBAIB/8QAFgEBAQEAAAAAAAAAAAAAAAAA
AAEC/9oADAMBAAIQAxAAAAHv4AHkeoAAAAAAAAAAAAABQk9yCNTWmpclpyXBYFPqII/hJkisen1H
4XySbX4SQK0kysSkqtUS5r6gAGfJRCxGnLxgx2c3x6z1cvLadBrnSWFcoTb1whOg1w9NeXyINN0a
yBPpMmTq1rgq47GmrkoAEWex+CQKelxWnJcVyxNTWLP0eJ9JnaamuWJqajIU0hfjSfWLSXXMksZa
lAAAAAAAAAAAEWSgABREvagD/8QAJRAAAgICAgEDBQEAAAAAAAAABQYDBAIHAAEgEhVACBARExQi
/9oACAEBAAEFAvCWaGDH5rm3WwcysHdB1zcn+UXljYKVUZeHtgpauT5K0rkGIc4FYadZmmne0Bmt
NyuzNIFOEiydEyOlaVyDEOcCsNOQ+FhuhGdcZcPXj6qJQeTy41toFJD0L9MpSItyuIrjyFEtScNj
pyH1DLHYi8WxUt3Sy9slnuOG9c/16ltyW8aCiMoi1OhLcmHjwdYrdVCJIsu3Li4P23rtQuKw5irO
Frd+j4PbVnb5Wdj2Npm1/Vq25cXB+29dqFxWHbEsKNDc+u1QvQt7QDE48dDFomETzaFyvTOaQwtY
6vmXsLf1N4YYRYNlqbYEeu7mZFB8TAQQw0R40cJqlRIw4P66/HBev0sMb5nr9LkZOJNDKN457KM9
6HiBorPpfCdGxwygIqJNDKN45ToZZ7m+2lYIYlTEGKwNsimuN9SOOOGPsCH7O82rkND61Rw8y+mf
IDhhgCj4lNdgTbJ4f//EAB4RAAEEAgMBAAAAAAAAAAAAAAEAEDFBIFARQEJx/9oACAEDAQE/AdId
AYw+tbWgjKEK2tig4hemlDrW4yMaDjH/xAAUEQEAAAAAAAAAAAAAAAAAAABw/9oACAECAQE/ASD/
xAA9EAABAwIEAgUKBAQHAAAAAAABAgMEBREABhIhEzEQFCJBYRUgMjNCUVJxkaEWJDSBBxdAgiNU
YnKSosH/2gAIAQEABj8C8zU86lAJABUbb/10Og0CniZVqkoiGwtVkISn0nXD3IT9+WJUnNWcW6i2
8EdXjtU9LKY59qxuSq/jhyXb9NUIT3ytJbv9uhOT5OZIyKku2mKVb3PIe6/hz6GKNmDMcaLJk+qa
dVv8z8I8T0TFya3GaTAcCJqnXQkMq0hViT4HHlChVWPMYvbixngtN/dtiXlAxUhEemMykO33UVrW
m3/XDNbnQ0R3y680+y2u6UqbcUg2P9uF1zMlRRGjINitQJufcANycMVamSA7HktBxlwe0ki4OJi5
NbjNJgOBE1TroSGVaQqxJ8DjyhQqrHmMXtxYzwWm/u2w/Tn6myh6Mwl6Qha7cNs3AUfDY4W7l6ux
JyWjZwxZCV6fnbGjUL25YfRAlpdMV8syAn2HAAdJ/Yj69Cq9mSbwIyFhJXoKtzyFhhqpU6Sl5h9s
LZdQdlJPI4flVPMENhuK6GpCnJCRw1kXCT42N7YbqVNlIfYeTqadbVdKh7xhv8T1cMKd3QhLSlqt
8Vkg2HjhL7K9SFp1JUO8edHzfRMwIp0+FHWzxJDAdZW0oglKxcd6RuCMR8sCRRq60tR65LoiXUiG
Lc1k6kc9rar4rS72tGTY+OtOHHqewl18NEstrXpClW2BPdj+ZWe5ztSqEusvPU+hNdkOzg6pscu0
4bp2vskd2GXqhFSzIUykvMpc1BC7bpv379+M1Z9/i1Vy1GYq3V5FIjq7D3CSlTber0ljtJskWuRf
EWpVajeT33m9SoXE1cIeyDsN7W27sZjDmXX65XFTGfJNKtdpH5du7yr9lPcNR3HdiRIrMlt6pVKS
ZNQUwnS2lZFghA+FIAGHIOU6hGhh/LDXW5j7WtTaeO56Cb7q+e2Khl4yXHTTK/MjFx09pX+JqufE
hQP74GUIZDsmNETHpcRX+akA6pB8GmhfwJxRDaxbhBlQ9ymyUH7pxmMOZdfrlcVMZ8k0q12kfl27
vKv2U9w1Hcd2JEisyW3qlUpJk1BTCdLaVkWCED4UgAYU/mimyak4qiR/J1HYbKxLe4rtrp5G3+rY
Ym5xzQyyxUamlCeoxfVw2U+g1f2jvcn34h5/y22pdRoSlOdXST+Zjn1rXzsLjxGK/mOPfgz8zyXo
+oWPD0thP2GLYyq7UHEojN1pbrqlnYaYzpBxS1ym9HFS462j4W1urUgf8SMKgVAcaEqD5TTFcF0c
XhhnVbv5YDbaAlI5ADljMojkqeb63Kq7lv00aNrTGjf3LTxCMUSc76TtJjqV8+GPOVTK5TmpUdRB
Uy+jUk23G2EwaVAZjMoHYaYbCEj9hhylViC1JjO+sYeRdKt74sMPZkpmXY7U19RK5ATc3PO1/Rv4
dH4vcy7HVUdj1lSb7/Fblq8efRm2pOxCjjVFhLbikW1pTGb5HvF+j8Q9UT13qvV+P38LVq0/XEhy
nxEtGXIL8kp9twgDV9AMHMgpTHXyzwjL4fb0e6+BApkRDDIUpQbbFhdSio/ck4zbUnYhRxqiwltx
SLa0pjN8j3i/RPqa4h0t5ejttvFG1+M6SAfp0ynI7SUNu1ycpCUjYDjqH/mF5jTEHXXIwYU/c+rB
vp93PDcHMtIamNNPB1tt3kFDvwGmkBKUiyUpGwGBmY09HXxG6uJPtcK+rT9ejMD/AAmmjKpzzZKU
gF11aNCfmSSMUqhyfWRKey05/uCBf+pFNpEQMsJWpQQCealFRO/iT5zOZau9MkqjLC2IbstRjIWO
Sw3yv5v/xAAjEAEBAAIBBAIDAQEAAAAAAAABEQAhMRBBUWEggUCRoXHh/9oACAEBAAE/IfgAOFMK
YG+6/nIRrucE3YE42kHNJXtnSOgEklqTBJpoeD1/XSYiXZ4qyHSNqkOhSWGahYQIiIQGYIlHFyCW
YCKGh+8ELj10c0nfrKzpDoJHgn9uO7OFZcbR2+8Ci5MJwAq8AuA0L9DTB2ae+LkEswEUND94IXHr
o5pO/WEwWlZQOhP6s3e46bwVZiJdtF7Tzj3Kp2weyr6dJ/cxy8AVf+OW8WyMoPswJ4TgTdaYdyOG
bueb4Q5MluujaxTlUK1Wc4NwLhEKPysLT0XypsCR74w0kIYVGWo0H0w93ehaX9mc6iP7oLCwsZhs
+tmmiEKKpf2tsU9wSkko0LLMibbeixJp0W4NhuVyKKtHkTGym5cRsNe5TsGqWA9sl/uuh2EELtle
cTaumWYyFX0cvYd4TrpwfugYQFcTGPeFqox5afQmB/SGI2Gvcp2DVLAe2S/3XQ7CCF2yvOayUhBP
DYp3C7QzSQtm7gPK4ataN8ZVwXNZyuJdM5xU2ubRQPMMpdt+MCjQ4dovjbiHk/P8RjPL0BmMbjY3
Lw8YcIZOB6MpWi1ojKaVknFxSuMfO/8AfkRT/iVsXMQcm8MOfoAMJOoESAUfCD/pgCEDgMVjbgVr
sllWS3fRWvNEpAAmYA14c9Gy2rUDYdxxq3p+1jfQLJz4uUF3DuFe0X1kMjyue+aZLUO0QZ7Y9uNl
tWoGw7jjVvTuZ43Ip5mweusdw8oeAcAThI2x0pMWNl4uAGsFQkNHelJw3eAP/IC0AdjKoLldn6vL
pWVgaImcZecZS/5Sn9X8lD2NhuEl2z7+Xcl07XGT5875+P8A/9oADAMBAAIAAwAAABAACAAAAAAA
AAAAAAAC2CgwmmwmUAWGGAAAoDzHVpDVJOLaGgAASQggAQQAAYUEagAAAAAAAAAAAQAAEAD/xAAe
EQEAAwEAAgMBAAAAAAAAAAABABExECAhQEFRUP/aAAgBAwEBPxD+EtQH7mOWXXFDlkEcl+6g2RQL
ZssgjkuCOeCgW8smxQ3zT7ILdTTgereVasGSy37AqN5noVPakwllv2BUa3AdYPsjsXjpwrh9Gewe
SDMm8oHlF3w18KL4a+LHEHeUXfNIFFfJAPJC+P8A/8QAHxEAAQQCAgMAAAAAAAAAAAAAAQAQMUER
ICFQMEBx/9oACAECAQE/EO7xnwidPjU3GEUIRlU1OXKpgj61OdhPS//EACIQAQEAAgIDAQACAwAA
AAAAAAERACExQRBRYSBAgXGRsf/aAAgBAQABPxD8GOqCGGoFAByqB/OPH/B4VagA7/4FaJ9GyzEC
DtVzXq5/wcyv+B8IsJR0tAlQAEQTwjCRqY4iAFiBUcBGRKI84tH66YgpP3sjkTJgUoUqGBpVspre
GIQrSLsKIm1p1kOUEEqIlOgyesaSrxOb+BJgWQUB4qkQASgMAnCDi0frpiCk/eyORMmBShSoYGlW
ymt5pgsATvmGrrlKUSYQ6JeQoKWUNXAwHOMiCDlBSv094tufqI8mjC9J34S1Qiez+tdGhGAuAciq
XluRB/vLAUZKY0SlsCE3non9GEEnsy28ljIWFQIgCoM4SUaOB8RH+/0BgpMchciwtlw0tr0D32ii
6c2qy0pOh/eD7jy6BHIY90MCsZMkK1lQbA9FsaXHMNt0CHkOk0LMC05dU0pMjUg2T/heSz467TtB
G8bAGLFmBgK87LI+HNeUM0tC4CQK7ZhA2dBcDnLWb44AlQFamEshj3wKNb1GiuE+L3ygv1N9HAje
NgDFizAwFedlkfDmvKGaWgriDVeC5uul8E8eAZeSgbN6AhOB78gA4msoyhIuGSnARObjZHTTrOu6
Xbc940SHQoGhSC8IZX+byWmuAgaAA0GHpsP65R2J54Vwx+SxnAGg+GOSMlrIkOCNtjwHYW/gqz/t
+gKzELpQQi9mB14XkQDhDowVY+nkcjH+gTZgcoABAPWKqa4ABRbBNNK+HFHCFbICRMg0Dwp0gaUk
CDOzDsPiobCLn2z0QvkDcJgXUYDduu5pDXVqn6bSMQ1xfRzAdAYXGyQ84792K4p0gaUkCDOzDsPi
qde9slEbBY1yeEEiYCoJ52jQAA0AGX00fP8AOAcQLVUAI6G5jICKyoICawxhDSAE0AABoDGkYRiF
JsZzSisQW4PYQGSoEF2pQy9VWENTnRMfP5IxEHpTIFrXlda/QTK7xRzsZE5Bh/P/2Q==
--15848047911.6F3Ff.23881--
The really weird part - is that the EXACT same code sends fine from one of my other servers. Yet, the MIME headers all look the same (minus having different part ids and date stamps obviously :)). I've got the host looking into this - in case its an Exim issue on their end, rather than my code. Seems very odd though!

Inline Images are Broken

I'm trying to send an email with an inline image. I've set the Content-ID and added a <img src="cid:image1#myemail"> to my html. The image arrives properly as an attachment, but mail clients show a broken image.
What am I doing wrong? The full source of the message is below:
Return-Path: <igal#lucee.org>
Received: from 128.149.80.230
by smtp.googlemail.com with ESMTPSA id i7sm9313707paf.9.2016.09.01.11.15.59
for <igal#lucee.org>
(version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128);
Thu, 01 Sep 2016 11:15:59 -0700 (PDT)
Date: Thu, 1 Sep 2016 11:15:54 -0700 (PDT)
From: igal#lucee.org
To: igal#lucee.org
Message-ID: <489410968.5.1472753755600.JavaMail.Admin#IS16>
Subject: [Test] LDEV-545 html 5.0.0.200
MIME-Version: 1.0
Content-Type: multipart/mixed;
boundary="----=_Part_4_247149912.1472753754816"
X-Mailer: Lucee Mail
------=_Part_4_247149912.1472753754816
Content-Type: multipart/alternative;
boundary="----=_Part_3_913848408.1472753754815"
------=_Part_3_913848408.1472753754815
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
Text Message
------=_Part_3_913848408.1472753754815
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: 7bit
Inline Image: <img src="cid:image1#myemail">
------=_Part_3_913848408.1472753754815--
------=_Part_4_247149912.1472753754816
Content-Type: image/jpeg; name=test-image.jpg
Content-Transfer-Encoding: base64
Content-Disposition: inline; filename=test-image.jpg
Content-ID: image1#myemail
/9j/4AAQSkZJRgABAQEAYABgAAD/4QBoRXhpZgAATU0AKgAAAAgABAEaAAUAAAABAAAAPgEbAAUA
AAABAAAARgEoAAMAAAABAAIAAAExAAIAAAARAAAATgAAAAAAAABgAAAAAQAAAGAAAAABcGFpbnQu
bmV0IDQuMC4xMAAA/9sAQwAKBwcJBwYKCQgJCwsKDA8ZEA8ODg8eFhcSGSQgJiUjICMiKC05MCgq
NisiIzJEMjY7PUBAQCYwRktFPko5P0A9/9sAQwELCwsPDQ8dEBAdPSkjKT09PT09PT09PT09PT09
PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09/8AAEQgAIgBDAwEiAAIRAQMRAf/E
AB8AAAEFAQEBAQEBAAAAAAAAAAABAgMEBQYHCAkKC//EALUQAAIBAwMCBAMFBQQEAAABfQECAwAE
EQUSITFBBhNRYQcicRQygZGhCCNCscEVUtHwJDNicoIJChYXGBkaJSYnKCkqNDU2Nzg5OkNERUZH
SElKU1RVVldYWVpjZGVmZ2hpanN0dXZ3eHl6g4SFhoeIiYqSk5SVlpeYmZqio6Slpqeoqaqys7S1
tre4ubrCw8TFxsfIycrS09TV1tfY2drh4uPk5ebn6Onq8fLz9PX29/j5+v/EAB8BAAMBAQEBAQEB
AQEAAAAAAAABAgMEBQYHCAkKC//EALURAAIBAgQEAwQHBQQEAAECdwABAgMRBAUhMQYSQVEHYXET
IjKBCBRCkaGxwQkjM1LwFWJy0QoWJDThJfEXGBkaJicoKSo1Njc4OTpDREVGR0hJSlNUVVZXWFla
Y2RlZmdoaWpzdHV2d3h5eoKDhIWGh4iJipKTlJWWl5iZmqKjpKWmp6ipqrKztLW2t7i5usLDxMXG
x8jJytLT1NXW19jZ2uLj5OXm5+jp6vLz9PX29/j5+v/aAAwDAQACEQMRAD8A9mooqvNfQW95bWsj
kTXO7ylwfm2jJ57cU0m9gLFFUdK1qx1uGWXT5xMkUhif5SpDDtggetGnazY6sbkWM4l+yymGUgEB
WHXk9fqKt0pxveL038hcyL1FUdL1ix1mxN5YTrLbhmUvgjBHXrVaHxRpk80aRSzMkjiOOf7PJ5Ls
TgASbdpyenPNP2NS7XK9N9Ng5l3NeisuPxFZTXr2sK3cskc3kOyWkrIr9wXC7RjPXNalTKEofErA
mnsFFFFQMKwtX/5Gvw/9bj/0XW7RWlOfI7+TX3poTVzzLSGutB0y3uLBCzawJbUYHC3PnP5bn22s
2fZBV4xto9l4g03TR/pEs9vY22TglmgRdxPrjcxPtXfUV3SzDmk5OO++u+qav6JWMlSsrXOANlf2
iavpC2cdl/aViWtIYp/MG+NAjAHaOSu38iauyeI0a50eHSNRjRZJooJdOMI82Nf4s55XAGOldlij
AznHPrUPGRl8cP6tbqn2XnvrqP2bWzOK0C+trfXtTim1xLd31SULYsYx5pOADyN3J9D2rtqTFLXP
XrKrLmSt/Xoi4x5VYKKKKwKCiiigAooooAKKKKACiiigAooooA//2Q==
------=_Part_4_247149912.1472753754816--
I found the problem. It is missing Content-Type: multipart/related;

Gmail API In-Reply-To not working(Google not handling on one side)

Problem: When Reply to email is sent via api then in receiver side it is showing as thread that contains two email messages(good on receivers side) but the sender has two different emails one in Inbox and one in Sent Mail(Problem in sender side).
for example:
Email is sent from A to B.
Again B sends to A.
here in api i am giving the previous email message-id in "In-Reply-To" and "References",(according to rfc822 format) here Google is handling that message-id on the A side but not on B side. A receives the message in a single thread as two messages but in B's account it is showing as two separate emails one in Inbox and one in sent.
Api used:
https://www.googleapis.com/upload/gmail/v1/users/me/messages/send?uploadType=multipart
Content-Type: "message/rfc822; boundary=foo_bar_baz"
request body is in rfc2822 format
Noticed this in my production app today as well. The change log did not give a clue as to what happened, but I found the problem in the new documentation for managing threads:
The requested threadId must be specified on the Message or Draft.Message you supply with your request.
The References and In-Reply-To headers must be set in compliance with the RFC 2822 standard.
The Subject headers must match.
In other words, the threadId needs to be supplied. I don't know if this is a bug or not, since it is not documented in the sending message-documentation that was updated on the same day.
I want to respond to the latest message in my inbox. Let's get the relevant information:
Request 1:
maxResults = 1
fields = messages/id
GET https://www.googleapis.com/gmail/v1/users/me/messages?maxResults=1&fields=messages%2Fid
Response 1:
{
"messages": [
{
"id": "15071b210a1ac883",
"threadId": "15071a4886871a10"
}
]
}
Request 2:
format = metadata
metadataHeaders = In-Reply-To,References,Message-ID,Subject
fields = payload/headers
GET https://www.googleapis.com/gmail/v1/users/me/messages/15071b210a1ac883?format=metadata&metadataHeaders=In-Reply-To&metadataHeaders=References&metadataHeaders=Message-ID&metadataHeaders=Subject&fields=payload%2Fheaders
Response:
{
"payload": {
"headers": [
{
"name": "In-Reply-To",
"value": "<CADsZLRyej6wRwCNYv91+dBu9uYhuqYo4pEqOpt41NftXJJqC7g#mail.gmail.com>"
},
{
"name": "References",
"value": "<CADsZLRyej6wRwCNYv91+dBu9uYhuqYo4pEqOpt41NftXJJqC7g#mail.gmail.com>"
},
{
"name": "Message-ID",
"value": "<CADsZLRzipMRrQv-A9m-r-EJafXXm1eS9ihw3ZD5g8ybfj+LYeg#mail.gmail.com>"
},
{
"name": "Subject",
"value": "Re: Perculiar"
}
]
}
}
All that is left is to create a message with all this data in the right places:
Request 3:
POST https://www.googleapis.com/upload/gmail/v1/users/me/messages/send?uploadType=multipart
Content-Type: multipart/related; boundary="foo_bar_baz"
--foo_bar_baz
Content-Type: application/json; charset=UTF-8
{
"threadId": "15071a4886871a10"
}
--foo_bar_baz
Content-Type: message/rfc822
Content-Type: multipart/mixed; boundary="foo_bar"
In-Reply-To: <CADsZLRzipMRrQv-A9m-r-EJafXXm1eS9ihw3ZD5g8ybfj+LYeg#mail.gmail.com>
References: <CADsZLRyej6wRwCNYv91+dBu9uYhuqYo4pEqOpt41NftXJJqC7g#mail.gmail.com> <CADsZLRzipMRrQv-A9m-r-EJafXXm1eS9ihw3ZD5g8ybfj+LYeg#mail.gmail.com>
From: emtholin#gmail.com
To: emtholin#gmail.com
Subject: Re: Perculiar
--foo_bar
Content-Type: text/html; charset="UTF-8"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
<div dir="ltr"><b> This is where the message text goes </b></div>
--foo_bar
Content-Type: image/png
MIME-Version: 1.0
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="cool.png"
iVBORw0KGgoAAAANSUhEUgAAADAAAAAwCAYAAABXAvmHAAAAGXRFWHRTb2Z0d2FyZQBBZG9iZSBJbWFnZVJlYWR5ccllPAAADd9JREFUeNrsWnuQXFWZ/+6j+/ZzeiYzk5lkHkkIM3nikIeTEARqNYRSKRXcxQGxLAqipiJBUlIqurvlupavKikpdpFQiFVLJOADUcLKbBCVoCRAkCSEJJPJTCbT8+qeft7345z9zr2nZzoyIRMS/7CKmzq5nb73nvs9f9/v+zoCpRT+kQ8R/sGP9xR4T4ELPOTKh3k3P3xeD9av69rg2lYPUc11rm4sclU95RlWiNi2IIbDVFIUR5BjRUGMDohKZJ+sKLvKA2/8+XzeMbbrc2f8eybAkc9X4zndy+91imqPdrR/WWt7k9x5SRMsbaqDtvooiFIIcqYAQ1lTyBXK4Ym82pgpW435ktpdGhveotS2HBXk8C4zO/Dti+UBoaLVuTwwZ/3Kzzv54rYkoUuvXLFA/PT72yBrhuHwiAlH00UYSGdhMl8G3XYgJAkQCYmQikehtjYFDakoKIIDRwYzkB7LeLYnHEd73m+XJn58oR6YlQK1XR1PSJOFj1+3boly/aoO2HtChRcOj8PpsRwQ1+Z3EXwDewvBFxG2sX8Gtr9AIRmNQGtjEloaknBiaBQGhkZNTww/c/qRf7mpuWcH/bsoULd61WK3lN/ZUR9b94UPLYcDaQl+tf806OUyEOKyLZlsvpDsD1QE5p/Z3gJXCNj9hIAkS3BpcxLmJmV4vW8McmXtVWqWP00k5fhFzQEmvKjmnr66o2nFxrVdsGPvBBwbHAJiab5FBQZggfS+4QUOahVFqCD4lyn3DiWBEq6uw5ETeRhPRuDyRXXQN0zWpifMp6g+eQON1h+/aDBq5/I71y9qWrGiowv+4xcDcOzkMBCbCS8E4lbOuAT8zASmU98z3QTuIeoLT6mD8lu4TABHg8zEKPxx30FoVAxoTAjLQQw/jhYPXZQkTnZ2PHFpTeimz1x3JXzzl/3gajm0nhMIGjzmC0ccDwVygXoeF5KHkJ8DHt6FZ4kpwe4xgTomPoMKuAYqYeGeFgieC0vb62EwtBxKA68+Pb773//5km29LrENoKgwW+A5uK0XeFQIHH/qsTtmDqHarpWfFyfGP77lk9fAjpdGgehFfJHNw0PwRSceAc92URgMCaMMnqXipg7e4qKSLHnxLiKi8DJCqxgoQ1FYtL7AFGHCeUwR2z+naQNsuOnDsOfBkQ/P3bj9zpP3b7ofDest+tyvUFoJhXanhYepeJ1ZAStb3PaJ7iXKa8MUY34MPFcP4p0HG3FReBTcKaHgdgG/0E1iaKecYvqQPfL6IWvoL0NK+xXtSsvll4VS8y6jkfgC1DwioqAiRaE9tCgLIzf4HG6dB1d/eSvckhAgs+FD4TdetLfjax5Gb2uLvvBrZvgggavlpmdRINm5/N64WVp6/epFsH3nMfRwGZ8Sp9xGMFQIWt4q5DEccpar5Y+pB5/8H2sYoQnTBhe6AZ3S//wIrv1s/0jr2vbEyo9thnjdcmp6YZF5AUOHoleV+a1w7T3b4VZM6C/tHIObu+JQKF/TSp0fPDjy1D23gyDbIIqB6NUanM0Drqr2fGDVAvGlEyVQ1fLUMwxZiOv5lrcKRQyBrG5P9PcW/vTdXXhZx1Xki31G0wKzm4QrYg6/ehrX4boPbN0cbrz0RuKoMcGxITKvDa696264rV6BrY/2gVYswMP/58Ki5hqo6bzyFunWn/x04MHrf7/wjifplOz0HVAosbBrg1fILbt1/Xz4w+EJPzH9lKUcSTDZXA1RCC1vZ3zhd+Jjk7gGcfXhOolrCNcIrlF+HuLf9+X3/tf3nWzf4xBvtCKtHfBPW+6GzzYr8MUdB0DLoAONSfDMEvSdGsdccUSlvu03C27/2QaWRwLzAlvc8nQmDxBi9rTMa5KzhginxvIBdlPRT0pmfT98rBJ4RuFY4Y++8Flcw7gmmOWxmrp/YxyPLwvhEWEHtNyL//2dhZsfXXPlp265/MZGEbY88AKUMBwZkgmC6EMwO7loV0EOxaRQ/FmE3k2iHN7nMT+gESlDtpk8QG1z/bL2BjgyoqO1be6uoJoCCu9qKsatbqoHf/4oXihw4cdwqTMIf8bBr6trdvS1ru/5zJL1UQJfeWgPOAVEOQ1DEosjQTRjy9PxbGL4GgVGU5Io7HOoVbcUUlApOVB0pkrsGcbC97Ul4c1RjfMXVjnxcTHgNR4WH2Kqp8yhl/vx9vEqy5PZFJwrnqFrW+Pw207biD6w6w/gaRmQEXo9ywjqCKVBWUSqgdYHKklUkBwihqI1CKW9iISbREnZT3wkdN/uAc/UUyvwDQOjk5wO0AoBwfCjPs67pbG/8mTNno/wi2/d3N0egz1LTCP5xO4XwNYy6GTb50aebSGian698cyiX1MwGlhhxPrnOdSxiUBICrfppaLYjUr49eXtOeBaofl1URifLPkErBqzBF8ZD6zRg69xBc4ZNpVj4Q2bu4009L7e91LypfQRZj1CXcICWRZCgl+dgVVbNBCrNyKR8G/MN2ZD17Jd2xYF0EQpLKekSLwXpNAmdNn+tylAPUeQUDPNdDinAS44cNJGwBzY28eh0p6N8InG9u7R3T/ttctqyiobPhj4pA5FFvFlyToFgYFBveejjG9ZPLsOQZ0MhHXNQk3DPrMSBUFWyilBFnvlECoBsP8MBfBh2jdWFqKyALpDOHUIPCGSINpiHR9sV998mnlhVtZXM0PsJbWgKBDGNW01dz0VQ3/56Lq58ORz+3DrEBdeQrqN8U9lzIEYzey+uwdvP4QrczY6PZUDgig7R07lsPGQprk9gyw8i5jQAm4eab18NYdGciFtoBRv2BiNxaBoY7hEanGlQFSSIESSeDGK2BFinvKm6O5s6DRCcOnoUBbqE2EEIDrFKpnWclhEC0ZBrpm7hlfYC5tmSOFNTU1N2JIiLCoJACUCEMKeWkQvofAe8UNa57WXzq4fIGRocKIEjXVx3h7yJoQGCTUHv8cgXJxa3bPk3QwDKke8uaMFk3NVZ1s9jJdxYznsCy6IDDpRIeynCZZaahkZzq3ILBsa+sp43oB6JFYVbs+oBDsbtgfxSAQSiUQ0uvjqb+LN4XerAEpzX8v85gSj5BOTRQb8SA3EwNQMsknQFLna5HEOFt6sFKCW+otiqYSwbEAyIgU5QIIiRrChyGsWLGptBCWWWNN80wP3Ij04by+klq7cqtDixz64ejEcwnzzWFMj8C4DhZb8dyE+iIJnj77xIqMh5wKMKQVGfn7nXqyI/a+8NQwNqfDUdKGSzMwLWY3Ais6FSiSWurP1tse/gUoIsxW+9n0rt0qF8e/f9pErlD8dPg25fMHnWYyZ+SMBNJaM/7bwPUgpRrRjzx3kkO3OMoTAIbb61OhkiSQVGSSeP5TnArNMvqjBeNGErqUL4iGBfHXBlmeejjZ1LHxHwS9b1VKzpOMJKTPxw203bIjteW0QhofT6HGdp2eF8WKNwGaJiCKxJ0/9mQuv8jw4d08sCH43XjOv58cHGupqL4nFIjBWMDl5Cnphwfe0BA2Y0B1tDfDWQAay+YIqhhOvS9FUr5xUnpNj4hvYtXUhEbsO+dUmUi6t6mxvStyxcTn8ZM8JOHryFNIFnRfJYBzDeuswWt/QLXBcM5195p5tnKYz3lWqINE7jlXYcInRXk/NPjIpiP+myLISlUUwWVETAun959EbE7kyOJ4Aa5e2QG2kJXFkqHDVcE69qpAe+pat6xBGjJ/TMAeWtM2Fa1csRdeK8KPfvAnDo+PIc3QeloFAFOFexGU5SOwkwbZOv/k7bnnG6Y1zwegZUwke07XNN/7wyVC0dmNDbRImNVbqxTN3EYKugn3PPNG9rBW6FtbCggZEKkWC0aIN/RM69I1ocHAwA8cHRpC06dNDL04SWXgSGzkQdno2fu2WJ/blnv/W96oaoUK1ArOazKESDCKbmz/5o9+FozXL4jEFNMvzQ0nwW9PqvJ3BOFWhEQy2gifo1MSO9xkIo4wWsx6bcTvq6v3ZZ7/2dU7T+3mvYZ9rMjdTRWVJk9OO7fmSpZcGyqoBcQylEBO+CpVo9RgR6NQ1Sqev0alrVWNHyvtrtLxr2uB6TBlzqHTgZw/weGeC586VvGdVgA9ajfLh376iHdl9l60Xj5c0HSEOi1kI6W5VfZgeGXLF/OJHpjzh03JCp2OeoZnrBFZHFkrQqwQtX3rtsfvssUMneC/NFDDONvCd1WgRH2bVr6we7X154tfbb7ZK43sLqoasWIeIRKGGcSOpEi7T0+ggriuTuWkPUcKQBpMUmxhHN8FmzUxItl11fN/k/37tX7nwbAiQZu/l77+w2ShvWFgSnc4++407rfShh0y9nM6XDZIvaSARF1IhgCSGF6PgkigEbWglTNDaLgsThEbXMFFwhEjWa0gSy9y0MfjKY/nn//O+qv6azZYKs22UZv37AKcMSaYTW3VX3XW7XNd2tagk5mOrJ4kouCzxWsFaRBJUVcL2ZZZnZ7xHlGXP00sjzuTgy8V9Dz7F50cFHjJj3PLu3+UHDtyIBUyU/VCDq5H9RBbrvG6N0tJ1jRyv7xBC0QZsSGLYMyDBFxidxKjyPIx3nVh6FmvLCSt94GXj5AtvcWRR+UwpwxPWmClszksBQTgnrWE3sPF33O+yAOoYP8MV4+xU5r2CNMNsyOWCV6Z4eW59jaPNrBL2QhX4W0WiXJkEV0LhioSmJpKBcDZnlRVuo/EKO2vBL7YC1YqIXGC5ygNilQKkygNuVYPyrv6Dxjsq8N4v9e8p8O6O/xdgAJ6nOBN0fGQLAAAAAElFTkSuQmCC
--foo_bar--
--foo_bar_baz--
This results in a new message with an attachment threaded like before:
To get it to thread on the senders side also you need to specify the Message.threadId field as part of your send() call. (That does not currently happen automatically, unfortunately.)

InvalidParameterValue: Duplicate header 'Content-Type' when send RawMessage with Amazon SES

I'm trying to send a raw email message with Amazon SES API to include attachment.
SES reponse with 400 status code and I not sure what I'm doing wrong, here is the response:
<ErrorResponse xmlns="http://ses.amazonaws.com/doc/2010-12-01/">
<Error>
<Type>Sender</Type>
<Code>InvalidParameterValue</Code>
<Message>Duplicate header 'Content-Type'.</Message>
</Error>
<RequestId>ad8cb17c-a8a0-11e4-8898-8924aa87abfa</RequestId>
</ErrorResponse>
The request signed and work OK with other request, so I think it must only my email message issue. Here is my message data:
Cc: my-verified-email-1#gmail.com
Subject: Hello testing email hahahahaha
Mime-Version: 1.0
Date: 30 Jan 15 23:54 +0700
Content-Type: multipart/mixed; boundary=7f1a313ee430f85a8b054f085ae67abd6ee9c52aa8d056e7f7e19c6e2887
From: my-verified-email-2#gmail.com
To: my-verified-email-3#gmail.com
--7f1a313ee430f85a8b054f085ae67abd6ee9c52aa8d056e7f7e19c6e2887
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Hello <b>testing email</b> with some =E4=B8=96=E7=95=8C and Vi=E1=BB=87t ng=
=E1=BB=AF.
--7f1a313ee430f85a8b054f085ae67abd6ee9c52aa8d056e7f7e19c6e2887
Content-Type: text/plain; charset=utf-8; name="test1.txt"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="test1.txt"
dGVzdGluZyBzdHJpbmcgd2l0aCBWaeG7h3Qgbmfhu68K
--7f1a313ee430f85a8b054f085ae67abd6ee9c52aa8d056e7f7e19c6e2887--
OK, I just figure out that I was missing a new line before the first boundary line. The message should instead be:
Cc: my-verified-email-1#gmail.com
Subject: Hello testing email hahahahaha
Mime-Version: 1.0
Date: 30 Jan 15 23:54 +0700
Content-Type: multipart/mixed; boundary=7f1a313ee430f85a8b054f085ae67abd6ee9c52aa8d056e7f7e19c6e2887
From: my-verified-email-2#gmail.com
To: my-verified-email-3#gmail.com
--7f1a313ee430f85a8b054f085ae67abd6ee9c52aa8d056e7f7e19c6e2887
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Hello <b>testing email</b> with some =E4=B8=96=E7=95=8C and Vi=E1=BB=87t ng=
=E1=BB=AF.
--7f1a313ee430f85a8b054f085ae67abd6ee9c52aa8d056e7f7e19c6e2887
Content-Type: text/plain; charset=utf-8; name="test1.txt"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="test1.txt"
dGVzdGluZyBzdHJpbmcgd2l0aCBWaeG7h3Qgbmfhu68K
--7f1a313ee430f85a8b054f085ae67abd6ee9c52aa8d056e7f7e19c6e2887--