OSB email - forcing multipart/mixed - email

I am sending email using a OSB (11.1.1.6) service.
Some email clients do not pick up the attachments.
We have narrowed down the problem down to MIME Content-Type.
Going through OSB it sets the Content-Type to multipart/related. In order to get it to work (we tested this using ncat) we need to set the Content-Type to multipart/mixed.
I cannot however find any way to force OSB to set it to multipart/mixed.
This message does not display the attachment on some clients:
From: <nothing#example.com>
To: nothing#example.com
Message-ID: <xxx>
Subject: Subject 123
MIME-Version: 1.0
Content-Type: multipart/related; boundary="MIME_Boundary";
start=1389578236803081255-2926c9b7.148d69bfba8.7396
Return-Path: nothing#example.com
--MIME_Boundary
Content-ID: 1389578236803081255-2926c9b7.148d69bfba8.7396
Content-Type: text/html; charset="iso-8859-1"
Content-Transfer-Encoding: 8bit
<h1>Head</h1>
<p>Paragraph <b>bold</b></p>
--MIME_Boundary
Content-Type: text/plain; name="TEST.txt"
Content-Transfer-Encoding: base64
Content-Description: TEST.txt
Content-Disposition: attachment; filename="TEST.txt"
VGVzdGluZyAxMjM=
--MIME_Boundary--
This message displays the attachment:
From: <nothing#example.com>
To: nothing#example.com
Message-ID: <xxx>
Subject: Subject 123
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="MIME_Boundary";
start=1389578236803081255-2926c9b7.148d69bfba8.7396
Return-Path: nothing#example.com
--MIME_Boundary
Content-ID: 1389578236803081255-2926c9b7.148d69bfba8.7396
Content-Type: text/html; charset="iso-8859-1"
Content-Transfer-Encoding: 8bit
<h1>Head</h1>
<p>Paragraph <b>bold</b></p>
--MIME_Boundary
Content-Type: text/plain; name="TEST.txt"
Content-Transfer-Encoding: base64
Content-Description: TEST.txt
Content-Disposition: attachment; filename="TEST.txt"
VGVzdGluZyAxMjM=
--MIME_Boundary--
As you can see the only difference is the Content-Type.
So how do I force OSB to set the Content-Type to multipart/mixed ?

You can set the Transport Header Content-Type. I assume you are using the routing to call the BS service which has email configuration. From Proxy, where you are routing, in the request actions, add Communication > Transport Headers. From the drop down, select emails >> Content-Type.

After some communication with Oracle support we were pointed to apply patch 12585136.
This was one of the bugs fixed for OSB 11.1.1.7 (link)
12585136 - The Email transport generates multipart/related emails and not mulitpart/mixed
After we have applied and tested the patch I will update this answer with more feedback.

Related

Axis2 sending multipart response when content-type is "text/xml"

Axis2 by default is send a multipart response even when there are no attachments
Why is axis2 sending a multipart response & how to ask it to send a "application/xml" or "application/soap+xml" how to get rid of multipart?
In the axis2.xml I have
In the response I see
HTTP/1.1 200 OK
Date: Fri, 17 Feb 2017 01:07:08 GMT
Transfer-Encoding: chunked
Content-Type: multipart/related; boundary="MIMEBoundary_87162747c87b279f7caa4e1ab573d5d864a878de7fae1a0b"; type="application/xop+xml"; start="<0.97162747c87b279f7caa4e1ab573d5d864a878de7fae1a0b#apache.org>"; start-info="text/xml"
--MIMEBoundary_87162747c87b279f7caa4e1ab573d5d864a878de7fae1a0b
Content-Type: application/xop+xml; charset=UTF-8; type="text/xml"
Content-Transfer-Encoding: binary
Content-ID: <0.97162747c87b279f7caa4e1ab573d5d864a878de7fae1a0b#apache.org>
200<?xml version="1.0" encoding="UTF-8"?>
<List_Wrapper>
<_bp>
<_comments><_comment><content>Again a new comment this is a text type bp comment need to see this in the text json 1</content><published_date>2017-01-18T21:07:15</published_date><published_by>cyril furtado</published_by><company>Chevron Inc.</company></_comment></_comments></_bp>
</List_Wrapper>
--MIMEBoundary_87162747c87b279f7caa4e1ab573d5d864a878de7fae1a0b-
I too faced similar issue for AXIS 2 quite recently , so thought to answer this.
AXIS 2 by default support attachment processing globally, which might not be needed for all types of services. To resolve this issue I disabled MTOM processing globally by modifying axis2.xml file -
<parameter name="enableMTOM">false</parameter>
This capability can now be enabled on need basis per service basis by enabling this property via respective services.xml file

Thunderbird+Lightning is rendering an ics invitation inappropriately

Using sabre/vobject library I am creating an ics file like this one:
BEGIN:VCALENDAR
VERSION:2.0
PRODID:-//Sabre//Sabre VObject 4.1.2//EN
CALSCALE:GREGORIAN
BEGIN:VEVENT
UID:sabre-vobject-d4b1ccb3-2197-4ee4-aab8-7bc2516adbf8
DTSTAMP:20170123T182612Z
SUMMARY:testev2
DESCRIPTION:
DTSTART;TZID=Europe/Athens:20170214T090000
DTEND;TZID=Europe/Athens:20170215T170000
LOCATION:
ORGANIZER;CN=Organizer Name:mailto:organizer#example.com
ATTENDEE;CN=Test User:MAILTO:test.user#somewhere.com
END:VEVENT
END:VCALENDAR
Then using phpmailer, I am attaching the file generated to an e-mail message and send it to the users who are participating on the event. Users who are using thunderbird (with Lightning extension - which is by default on) receive the e-mail message in the following format:
As you see in the picture the ics file is parsed and rendered in the table at the bottom of the e-mail. However the table header (the one marked in red) is not displaying correct information. Test user has not ever cofirmed his/her presence, and if he does, the ics file does not provide any info about it.
Am I formatting the ics file wrong?
Is it a known bug of thunderbird / Lightning ?
UPDATE
The e-mail headers of the message:
Return-Path: <XXXXXXXXXXXXXXXX>
Received: from deliver ([unix socket])
by mail (Cyrus v2.3.16-Fedora-RPM-2.3.16-13.el6_6) with LMTPA;
Tue, 24 Jan 2017 12:48:10 +0200
X-Sieve: CMU Sieve 2.3
Received: from [XXX.XXX.XXX.XXX] (XXXXXXXXXXXXXX [XXX.XXX.XXX.XXX
(using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits))
(No client certificate requested)
by XXXXXXXXXXXXXX (Postfix) with ESMTPSA id 6F18C1BE0305
for <XXXXXXXXXXXXXX>; Tue, 24 Jan 2017 12:48:10 +0200 (EET)
Subject: Fwd: Event invitation: testev2
To: "XXXXXXXX" <XXXXXXXXXXXXXX>
From: XXXXXXXXXXXXXX <XXXXXXXXXXXXXX>
X-Forwarded-Message-Id:
Message-ID: <bac7749e-9699-1b50-9de5-27a510c663a4#XXXXXXXX>
Date: Tue, 24 Jan 2017 12:48:09 +0200
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101
Thunderbird/45.6.0
MIME-Version: 1.0
Content-Type: multipart/mixed;
boundary="------------79DD2A1D49F1A57579125B45"
This is a multi-part message in MIME format.
--------------79DD2A1D49F1A57579125B45
Content-Type: multipart/alternative;
boundary="------------72E56459CD6D794D0DF5AC4B"
--------------72E56459CD6D794D0DF5AC4B
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 8bit
> ------- Forwarded Message --------
Forward message content
> --------------72E56459CD6D794D0DF5AC4B
> Content-Type: text/html; charset=windows-1252
> Content-Transfer-Encoding: 8bit
>
HTML Content
> --------------72E56459CD6D794D0DF5AC4B--
>
> --------------79DD2A1D49F1A57579125B45
> Content-Type: text/calendar;
> name="invitation.ics"
> Content-Transfer-Encoding: 7bit
> Content-Disposition: attachment;
> filename="invitation.ics"
>
ICS Content
> --------------79DD2A1D49F1A57579125B45--
You should make the Content-Type of the ics attachment something like:
Content-Type: text/calendar; charset="utf-8"; method=REQUEST
The method option is the magic word. I'm not completely sure this works, but it is at least closer to the spec. I'm happy to update my answer if it doesn't work.

Difference between message headers: Content-Type: charset="UTF-8" and Content-Transfer-Encoding: 8bit

I had received some mail message, but I was confused with these headers:
Content-Type: text/plain;
format=flowed;
charset="UTF-8";
reply-type=response
Content-Transfer-Encoding: 8bit
If Content-Type: charset="UTF-8" is already specified, so why we need Content-Transfer-Encoding: 8bit?
Because you can also have:
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: base64
The charset is independent of the content encoding.

Which Content-Transfer-Encoding should I use?

I am programmatically sending a Content-Type': 'multipart/form-data to an endpoint and my system (Ubuntu) is default on UTF-8.
My question is, which Content-Transfer-Encoding should/do I use?
Here is an example of a form part:
Content-Disposition: form-data; name="to"
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: ?
jacob#example.com
Which Content-Transfer-Encoding would be the safest to use?
Another example:
Content-Disposition: form-data; name="message"; filename="message.mime"
Content-Type: message/rfc822; charset=UTF-8
Content-Transfer-Encoding: ?
From: jacob#example.com
To: jacob#example.com
Subject: testing Coreor
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
testing Coreor
I have updated my code to use quoted-printable, so I now send the below.
It works, but do you see any errors, problems or optimizations?
--x.ai/coreor=---14187500275550.5525101518724114
Content-Disposition: form-data; name="to"
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
jacob#example.com
--x.ai/coreor=---14187500275550.5525101518724114
Content-Disposition: form-data; name="message"; filename="message.mime"
Content-Type: message/rfc822; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
X-Mailer: x.ai Coreor v1.test
From: =22Jacob=22 <jacob#example.com>
To: jacob#example.com
Subject: testing Coreor via Mailgun
Content-Type: text/plain; charset=3Dutf-8
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
testing Coreor
--x.ai/coreor=---14187500275550.5525101518724114--
I use mimelib for the quoted-printable encoding.

Nonstandard DMARC report sent by Google

I'm working on a system which parses DMARC reports and I figured the following issue:
Sometimes, Google sends nonstandard e-mails, as can be seen below:
MIME-Version: 1.0
X-Received: by x.x.x.x with SMTP id xxxx.xx.xxxx;
Thu, 22 Aug 2013 02:13:03 -0700 (PDT)
Message-ID:
Date: Thu, 22 Aug 2013 09:13:03 +0000
Subject: Report domain: example.com Submitter: google.com Report-ID: xxxxx
From: noreply-dmarc-support#google.com
To: postmaster#example.com
Content-Type: application/zip;
name="google.com!example.com!1377043200!1377129599.zip"
Content-Disposition: attachment;
filename="google.com!example.com!1377043200!1377129599.zip"
Content-Transfer-Encoding: base64
UEsDBAoAAAAIAEJIFkMWecIj/AEAAKkEAAAvAAAAZ29vZ2xlLmNvbSFsYW50aWFuLmV1ITEzNzcw
...
AAABAAEAXQAAAEkCAAAAAA==
Please take a look at the unusual break line between Content-Disposition and Content-Transfer-Encoding headers.
After the MIME standard, the content of the email should look like:
Content-Type: application/zip;
name="google.com!example.com!1377043200!1377129599.zip"
Content-Disposition: attachment;
filename="google.com!example.com!1377043200!1377129599.zip"
Content-Transfer-Encoding: base64
UEsDBAoAAAAIAEJIFkMWecIj/AEAAKkEAAAvAAAAZ29vZ2xlLmNvbSFsYW50aWFuLmV1ITEzNzcw
...
AAABAAEAXQAAAEkCAAAAAA==
This break line should not be there (you can see http://en.wikipedia.org/wiki/Multipurpose_Internet_Mail_Extensions ).
So, why Google do this?
If you were to join dmarc-discuss#dmarc.org and post this question there, I can assure you it would be read by a Google engineer that works on DMARC. When I wrote my DMARC implementation, I too discovered a number of variances between the reports I received and the DMARC draft spec. Not too long after reporting the variances on that list, they were all corrected.