InvalidParameterValue : Illegal header
jonatrey opened this issue · 10 comments
Hello,
Thanks for this transport layer, that's very useful.
I'm using it in a symphony task with the basic implementation as described in the doc...
When sending HTML messages (Content type header is defined as text/html), I get the following response:
<ErrorResponse xmlns="http://ses.amazonaws.com/doc/2010-12-01/">
<Error>
<Type>Sender</Type>
<Code>InvalidParameterValue</Code>
<Message>Illegal header '<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http'.</Message>
</Error>
<RequestId>f3f322f2-0ec1-11e1-b20f-3fffda72cbb3</RequestId>
</ErrorResponse>
After investigation, I realized, what is before a colon is interpreted by amazon as the header name. Looks like this error is pretty common, but I haven't find any case where the body was interpreted as a header.
I tried adding (did not work):
$headers = $message->getHeaders();
$headers->addTextHeader("Content-Disposition", "inline");
I've had this as well. What's happening is the line break between the headers and the body of the message are only two characters. I don't understand the stream writing stuff precisely, but since the Swift_AWSInputByteStream::write
method defers writing if the total size is exactly equal to 2, it makes it possible that the line break itself is deferred. The end result appears to be an HTTP request with no line break between the body and the headers (making Amazon correctly think that the body of the message is a header).
My current fix is to hack at the code and remove the line that defers streaming inside write
if the total_size and excess are equal.
Hope that gives some direction to someone else!
Hello,
I tried your hack. The positive point is that the emails are now sent. The negative one is that in some cases the email is not well received by some servers (for instance Yahoo doesn't get the body part).
Same email sent to gmail and yahoo.
Yahoo, shows an empty, mail, body is missing
Received: from 127.0.0.1 (EHLO a192-144.smtp-out.amazonses.com) (199.255.192.144)
by mta1133.mail.sk1.yahoo.com with SMTP; Mon, 21 Nov 2011 06:29:52 -0800
Return-Path: 00000133c68874dd-4aa25c79-2da2-4fd9-b86f-85d1035dff6e-000000@email-bounces.amazonses.com
Message-ID: <00000133c68874dd-4aa25c79-2da2-4fd9-b86f-85d1035dff6e-000000@email.amazonses.com>
Date: Mon, 21 Nov 2011 14:29:51 +0000
Subject: My subject
From: "My Sender" <sender@domain.com>
To: Jo <jo@yahoo.com>
MIME-Version: 1.0
Content-Type: text/html; charset=utf-8
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline
X-AWS-Outgoing: 199.255.192.144
Content-Length: 1
Gmail
Received: from a192-144.smtp-out.amazonses.com (a192-144.smtp-out.amazonses.com. [199.255.192.144])
by mx.google.com with ESMTP id z15si2024301vcv.4.2011.11.21.06.29.54;
Mon, 21 Nov 2011 06:29:54 -0800 (PST)
Received-SPF: pass (google.com: domain of 00000133c6887b7e-3e271f9a-c281-42bd-aee1-9e4ff651cd24-000000@email-bounces.amazonses.com designates 199.255.192.144 as permitted sender) client-ip=199.255.192.144;
Authentication-Results: mx.google.com; spf=pass (google.com: domain of 00000133c6887b7e-3e271f9a-c281-42bd-aee1-9e4ff651cd24-000000@email-bounces.amazonses.com designates 199.255.192.144 as permitted sender) smtp.mail=00000133c6887b7e-3e271f9a-c281-42bd-aee1-9e4ff651cd24-000000@email-bounces.amazonses.com
Return-Path: 00000133c6887b7e-3e271f9a-c281-42bd-aee1-9e4ff651cd24-000000@email-bounces.amazonses.com
Message-ID: <00000133c6887b7e-3e271f9a-c281-42bd-aee1-9e4ff651cd24-000000@email.amazonses.com>
Date: Mon, 21 Nov 2011 14:29:53 +0000
Subject: My subject
From: "My Sender" <sender@domain.com>
To: Jo <jo@gmail.com>
MIME-Version: 1.0
Content-Type: text/html; charset=utf-8
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline
X-AWS-Outgoing: 199.255.192.144
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://w=
ww.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html>
...
Did you test with different email providers to see whether the email went through?
JFYI, I had the same issues and after commenting out:
if( $total_size - $excess == 0 ) { return ++$this->counter; }
I am getting some messages delivered completely intact whereas others are delivered with no body; this is the same whether its google or my other provider (gmx) - i.e. provider doesn't make a difference for me, but the message body contents do...
Any more ideas on how this can be fixed?
Thanks
Hey Faz,
I couldn't get emails accuratly sent with this transport layer.
I tried using another one based on Amazon SDK, and as a result (see comment from 21st of Nov), Yahoo was fine whereas Gmail wasn't working anymore. After updating the swift mailer lib to 4.1.3, emails were delivered accurately.
I'd suggest you to try to update swift mailer lib first, I'm not sure the problem is on the transport layer.
Thanks Jonatrey - I can confirm that by updating my swiftmailer library this issue does goes away - and mails are successfully delivered... I assume this issue is now closed?
Hey everyone, sorry I missed out on the discussion here.
@faz , have issues resolved with a newer version of Swiftmailer?
@jonatrey do you know what the version of Swiftmailer you were using before 4.1.3?
I've got a different version of the base64 encoding in a new branch, https://github.com/jmhobbs/Swiftmailer-Transport--AWS-SES/tree/alternate-chunking
I thought that might be the issue, so if anyone is still having problems I would appreciate if they would try that branch for me, as I can't seem to replicate this bug locally.
Hi John,
I have to carry out more testing, but I believe the majority of test cases are passing. I had one case which was a simple HTML mail which failed with one ISP - but let me test some more with the new branch...
@jmhobbs I was using the one embedded with symfony 1.4. It looks like it was the version '4.1.0-DEV'.
I've just tested the new branch with a whole bunch of emails (as part of the Yii framework) and for me the new version works flawlessly.. I will continue testing, but currently I'm really happy with the new b64 encoding..
Thanks John!
Great!
I'm going to merge in the new branch, add a note about old Swift versions and then close this issue.
Thanks for testing!