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.
Related
I've had the following DMARC policy setup for over a year, but in the last two weeks I'm suddenly unable to send emails to many people. Yet I haven't changed this record. I am experienced with DNS, server administration and programming yet I cannot find any explanation for this issue.
What are the solutions to this problem?
Existing DMARC Record
v=DMARC1; p=reject; pct=100; rua=mailto:re+something#dmarc.postmarkapp.com; ruf=mailto:me#mydomain.com; sp=none; aspf=r; fo=1;
Error I get when emailing various emails (#gmail.com and custom domains).
https://gist.github.com/s3w47m88/115688a7ecd5a8c762bd3f98932756b2
Headers for Successful Email
MIME-Version: 1.0
Date: Wed, 10 Apr 2019 15:26:48 -0700
References: <BN7PR06MB4116507B5F036C4D175E082CC82E0#BN7PR06MB4116.namprd06.prod.outlook.com> <CAN9OK_OfgXw_mW2+M-=TkHLupnOdBo=VyE=wQOALykc8=EzjXA#mail.gmail.com> <BN7PR06MB411654D8A0AA5D44F92E1D1EC82E0#BN7PR06MB4116.namprd06.prod.outlook.com> <CAN9OK_PMipqHaLK9W-PAn0_dhsD876TpETq85CeVC5NBQpCPig#mail.gmail.com> <BN7PR06MB4116592A4D4E6B4EBE299EF5C82E0#BN7PR06MB4116.namprd06.prod.outlook.com>
In-Reply-To: <BN7PR06MB4116592A4D4E6B4EBE299EF5C82E0#BN7PR06MB4116.namprd06.prod.outlook.com>
Bcc: 5729491#bcc.hubspot.com
Message-ID: <CAN9OK_O-WEFqJysAr8S51LrBa1_fopy1UoFVSxq5JWNeeMuZCQ#mail.gmail.com>
Subject: Re: Your free trial
From: Me <me#mydomain.com>
To: John Doe <someone#asite.com>
Content-Type: multipart/alternative; boundary="000000000000d3115405863490ac"
--000000000000d3115405863490ac
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
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.
First of all: My reply-to header always worked for 2 years.. Thunderbird never had a problem with it and still doesn't have any problem on my Mac.
My shop contact form sends me the email from info#webshop.com and adds the reply-to header from the customer
The source of the email is:
Return-path: <sterntau#s207.rackspeed.de>
Envelope-to: info#sterntaufe-deutschland.de
Delivery-date: Mon, 04 Nov 2013 18:00:05 +0100
Received: from sterntau by s207.rackspeed.de with local (Exim 4.80.1)
(envelope-from <sterntau#s207.rackspeed.de>)
id 1VdNVV-001tmU-Gn
for info#sterntaufe-deutschland.de; Mon, 04 Nov 2013 18:00:05 +0100
To: =?utf-8?B?aW5mbw==?= <info#sterntaufe-deutschland.de>
Subject: =?utf-8?B?S29udGFrdGZvcm11bGFy?=
Reply-To: customer#gmail.com
From: Sterntaufe-Deutschland <info#sterntaufe-deutschland.de>
Date: Mon, 04 Nov 2013 17:00:05 +0000
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline
MIME-Version: 1.0
Message-Id: <E1VdNVV-001tmU-Gn#s207.rackspeed.de>
=0A=0AName: Test=0AE-Mail: customer#gmail.com=0ATelefon: =0A=0AKommentar: Test
Normally it should reply to customer#gmail.com which always worked till yesterday.
From yesterday its not working anymore. On all emails! Even on those where it worked before.
But it works fine if I send a normal E-mail from my Gmail account to my info#webshop.com account.
Reply-To works like it should then. Just not for the contact form
Thunderbird recognizes the reply-to email as it shows "Reply to: customer#gmail.com" below the subject. But still uses my info#webshop.com when I click "reply"
I also tried to re-install thunderbird, install thunderbird on a clean VMware. Install Thunderbird on another laptop.. all the same.
But it still works with Microsoft outlook
Please help me
It is a BUG of Thunderbird 24.1.0 https://bugzilla.mozilla.org/show_bug.cgi?id=933555
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.
I've a small site designed to sell a HTTP-downloadable, ~300 MB PDF, No-DRM, page-scanned images e-book (download the test copy here http://test.magicmedicine.eu/get/ac123457965d0d4b4d17557a73cf2fe8 ).
It works flawlessly on PC, Mac and Android, but I'm experiencing issues with iOS: when the customer opens (I tried via broadband Wi-Fi+DSL) the download URL via Safari, the page loads for ~45 seconds (the page is blank but the activity indicator rotates), then Safari exits with no error messages at all.
I tried to create the PDF with the "Fast web view" (=progressive download) attribute and I also lowered the compatibility to the minimum (PDF version 1.3), with no results.
Application-side, the download is sent from Apache+PHP via mod_xsendfile ( https://tn123.org/mod_xsendfile/ ) to the client with the following headers (my intent is to avoid the PDF-in-the-browser-via-plugin view):
HTTP/1.1 200 OK
Date: Wed, 23 May 2012 09:50:13 GMT
Server: Apache/2.2.15 (CentOS)
X-Powered-By: PHP/5.3.13
Expires: Thu, 24 May 2012 11:50:13 +0200
Cache-Control: must-revalidate, post-check=0, pre-check=0
Pragma: public
Content-Disposition: attachment; filename="book.pdf"
Last-Modified: Sun, 20 May 2012 11:26:54 GMT
ETag: "2e01b4-dde8a9b-4c07610070008"
Content-Length: 232688283
Keep-Alive: timeout=5, max=100
Connection: Keep-Alive
Content-Type: application/octet-stream
Any ideas?
Note: I asked this on SuperUser a couple of days ago and was closed as "off topic". I hope here it's ok to repost it here.