TYPO3 Core

Hi Franz,

A simply solution is to always quote the name. This would prevent this problems. The RFC check is done by third-party code and maybe you should report this bug in there project. At least it's really annoying that this often case doesn't work with TYPO3 anymore.

RFC 822 requires that any name containing control characters (decimal 0-31;127) or spaces (decimal 32) must be quoted.

Is this mail sent by the core or by an extension? If it's sent directly from the core (login notifications, etc.) please give some more details.
In case it originates from an extension you should file a bug report with the extension author.

This is from an order confirmation email in tt_products.
Must a single (') or double (") quote be added around the name?
Double quotes do the job.

However this should also be fixed in TYPO3. method t3lib_htmlmail::sendTheMail

Double quotes are needed here. RFC822 says that <">, "\" and CR must be quoted inside double quotes, so
$name = '"' . addcslashes($name, '\\"' . CR) . '"';
will probably do the trick

I don't think that the TYPO3 core should fix incorrect data. It already validates the data and throws a nice exception which the calling code can catch and take appropriate action.

@Jigdal: Thank you for the code example. However what is the 'CR'?
Shouldn't also other characters be quoted in the email name, e.g. & ?

Hi Jigal,

IMHO all extensions that use the mail functionality of TYPO3 will have this problem now. Also the dot inside the name didn't made problems before, because it was tolerated. In my case I added a workaround in powermail exactly for this case, but this can't be the final solution for almost all existing extensions which use the old API.

I would like to know if the problem happens with the new swift mailer API too. Anyone knows that?

New function for tt_products:

function slashName ($name) {
$name = str_replace(',' , ' ', $name);
$rc = '"' . addcslashes($name, '<>&()\\"' . chr('\n')) . '"';
return $rc;
}

I will introduce this new function into tt_products. Also the comma ',' must be replaced by an empty character, because otherwis this causes troubles with following PHP code and explode on ','.
I think that the '&' causes problems with mail servers.
The constant CR is in newer versions of TYPO3, since 4.4. I use chr('\n') instead, to support also TYPO3 4.3. I could not use '\n' here, because this leads to the result, that 'Franz' becomes 'Fra\nz'..

Hi Stefan,

All extensions which produce incorrect headers might have such a problem.
BTW it's not only the dot. Read RFC 822 and you'll see that any names with control characters (decimal 0-31), del (decimal 127), space (decimal 32) and: <>()@,;:\".[] in them must quoted.

The old API just passed those headers to the PHP mail function and then it went out of view more or less. You would never know if the mail actually arrived or if the name was displayed correctly.

The Swift Mailer takes care of all encoding and charset handling. Basic mails only need a few lines of code (comparable to the old API) but you are sure that the result is RFC compliant. If you directly use t3lib_mail_Message all quoting, escaping and encoding will be done for you.

Hi Jigal,

Thanks for this explanation! I would agree that this isn't an issue of the TYPO3 core then. Just a reason more to finally switch over to the swift mailer API. I will post a link to this entry inside the powermail tracker.

Is it planned to post an informative article about the migration from the old mailing API to the SwiftMailer API? IMHO this could help the extension authors a lot to release new version that use the SwiftMailer API or at least use proper quoting for the old one.

@Franz Koch: the Bug still remains when entering squared brackets

Is there maybe a way to check is in tt_products - to avoid this ugly TYPO3 Exception?

Grüße aus Mainz ;-)

It does not work to escape the special characters if I use the t3lib_mail_Message class to send the emails. I always get the exception thrown.
The email is sent if I use the class t3lib_htmlmail. However I can send the HTML emails only in the charset iso-8859-1. Where shall the charset conversion be done? Must every extension do this by itself?

Thanks for this explanation! I would agree that this isn't an issue of the TYPO3 core then. Just a reason more to finally switch over to the swift mailer API. I will post a link to this entry inside the powermail tracker.

Is it planned to post an informative article about the migration from the old mailing API to the SwiftMailer API? IMHO this could help the extension authors a lot to release new version that use the SwiftMailer API or at least use proper quoting for the old one.

So every extension that sends mails should be changed to work with 4.5? Completely switching to the new swift mailer api isn't possible, if you want /must stay compatible with 4.3 / 4.4

Just stumbled up on this bug on a fresh 4.5.2 setup with tt_products 2.7.1 (current version in TER) and this is a real showstopper for updating to 4.5