[TYPO3-core] RFC #17531: htmlMail - Can't send mails on port based systems with Swiftmailer substitution

[Ernesto Baschny [cron IT]]

Jigal van Hemert schrieb am 21.02.2011 22:04:

> On 9-2-2011 22:28, Stefan Galinski wrote:
>> Solution:
>> Use the code from Swift for the message id generation.
> 
> Or would it be better if the Swift Mailer Adapter just ignored ID
> headers? Swift Mailer will create an ID anyway if no ID was set.
> 
> Is there any use case in TYPO3 where ID headers contain essential
> information which *must* absolutely be part of the mail which is sent?

I discussed this with Stefan at the time the patch was created.

According to the RFC 2822 [1]:

   Though optional, every message SHOULD have a "Message-ID:" field.
   Furthermore, reply messages SHOULD have "In-Reply-To:" and
   "References:" fields as appropriate, as described below.

And from the same RFC:

   The message identifier (msg-id) itself MUST be a globally unique
   identifier for a message.  The generator of the message identifier
   MUST guarantee that the msg-id is unique.  There are several
   algorithms that can be used to accomplish this.  Since the msg-id has
   a similar syntax to angle-addr (identical except that comments and
   folding white space are not allowed), a good method is to put the
   domain name (or a domain literal IP address) of the host on which the
   message identifier was created on the right hand side of the "@", and
   put a combination of the current absolute date and time along with
   some other currently unique (perhaps sequential) identifier available
   on the system (for example, a process id number) on the left hand
   side

SwiftMail has a method to auto-generate one ($message->generateId()),
Stefan mentioned at the time we discussed it, that it wasn't being
called automatically. So he ported that functionality to this patch.

But looking at the source code of SwiftMailer, every Transport (even our
own MboxTransport) calls $message->generateId() in its "send()" routine,
so in fact we should have a Message-ID being added to *all* messages
that go this way.

So if its not happening to you, Stefan, maybe we could debug why this is
the case, because then this is another bug (and then the fix for this
17531 here is simply to skip the generation of non RFC-conform
Message-ID generated by t3lib_htmlmail.

Cheers,
Ernesto

[1] http://www.ietf.org/rfc/rfc2822.txt?number=2822