0

I have a strange problem.

I am using PEAR SMTP on Ubuntu. When I send this message:

--==Alternative_Boundary_x{da5ccf044317613d9f8e371455f292a6}x
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit

hello world - plain text test
--==Alternative_Boundary_x{da5ccf044317613d9f8e371455f292a6}x
Content-Type: text/html; charset="utf-8"
Content-Transfer-Encoding: 7bit

<i>hello world - html test</i>
--==Alternative_Boundary_x{da5ccf044317613d9f8e371455f292a6}x--

--==Mixed_Boundary_x{e46253d4aad6aff75d74ef5eb064a626}x
Content-Type: application/rtf; name="attachment.rtf"
Content-Disposition: attachment; filename="attachment.rtf"
Content-Transfer-Encoding: base64

e1xydGYxXGFuc2lcZGVmZjB7XGZvbnR0Ymx7XGYwXGZtb2Rlcm5cZnBycTFcZmNoYXJzZXQwIENv
dXJpZXIgTmV3O317XGYxXGZuaWxcZmNoYXJzZXQwIENvdXJpZXIgTmV3O319DQp7XGNvbG9ydGJs
IDtccmVkMFxncmVlbjBcYmx1ZTA7fQ0Ke1wqXGdlbmVyYXRvciBNc2Z0ZWRpdCA1LjQxLjE1LjE1
MTU7fVx2aWV3a2luZDRcdWMxXHBhcmRcY2YxXGxhbmcyMDU3XGYwXGZzMzIgSGVsbG8gd29ybGRc
Y2YwXGYxXGZzMjBccGFyDQpcY2YxXGlcZjBcZnMyNCBIZWxsbyB3b3JsZFxjZjBcaTBcZjFcZnMy
MFxwYXINClxiIEhlbGxvIHdvcmxkXHBhcg0KXGIwXHBhcg0KXHBhcg0KfQ0KAA==


--==Mixed_Boundary_x{e46253d4aad6aff75d74ef5eb064a626}x
--==Mixed_Boundary_x{e46253d4aad6aff75d74ef5eb064a626}x
Content-Type: text/xml; name="attachment.xml"
Content-Disposition: attachment; filename="attachment.xml"
Content-Transfer-Encoding: base64

PD94bWwgdmVyc2lvbj0iMS4wIj8+DQo8YXR0YWNoZW1udD5pbiAueG1sIGZpbGU8L2F0dGFjaGVt
bnQ+IA==


--==Mixed_Boundary_x{e46253d4aad6aff75d74ef5eb064a626}x--

I receive it without one of the --==Mixed_Boundary_x{e46253d4aad6aff75d74ef5eb064a626}x (look where there are two in a row) missing. Some how PEAR smtp send sends the message with that missing.

But if I do it from Windows, using phplib, it sends just fine and causes the attachments to work!

I know I could use the PEAR Mime mail to deal with this, but unfortunately, I am working with legacy code and that is not an option since the message has already had all the encodings.

My question is, why does PEAR remove it? And what does it break the attachments when not there?

Thanks

Antony D'Andrea
  • 991
  • 1
  • 16
  • 35
  • What is *phplib* if I may ask? – hakre Apr 25 '13 at 13:24
  • A custom built PHP library. It is outdated and I don't think it is supported anymore. – Antony D'Andrea Apr 25 '13 at 13:26
  • And are you getting any error messages? Some hints what might be going wrong? Have you put error reporting to the fullest extend? – hakre Apr 25 '13 at 13:27
  • No error messages. I receive the email completely with all the attachments. But the second attachment does not get decoded. But in the e-mail that it does get done properly, the extra boundary is there. And I have checked, I am sending it! – Antony D'Andrea Apr 25 '13 at 13:30
  • Oh, and don't forget to verify that not your virus checker or something is removing an attachment. – hakre Apr 25 '13 at 13:55

2 Answers2

0

I can only assume from what you give, but the Ascii-Art in your boundary is really nice, but just probably a little over the top. It contains characters that are not allowed there per the specs, and that are the curly brackets. Maybe because of having an invalid email there, things get dropped?

hakre
  • 193,403
  • 52
  • 435
  • 836
  • Why do the not all get deleted. And why does it work in some cases? – Antony D'Andrea Apr 25 '13 at 13:32
  • Well, if the boundary is not detected (or the end of it), then this would create a single attachment. But that is just a good guess, the problem here actually is that you're not sending a correct email with those curly brackets in. I would not think too much about why this gets broken because it is broken (by the specs, this is in [RFC2046](http://tools.ietf.org/html/rfc2046)). Maybe a fallback mechanism is describben and in action in this case. But maybe it's just random because you pump fuzzy data in. / http://tools.ietf.org/html/rfc2046#page-22 – hakre Apr 25 '13 at 13:35
  • I got rid of the curly brackets for all of them. Now, none of the attachments or text work. But it is all in the source. – Antony D'Andrea Apr 25 '13 at 13:45
  • I consider your last comment as the test result of yours *getting rid off curly brackets* so the operation failed. Please restore and try something else. – hakre Apr 25 '13 at 13:49
  • But the now all appear. In the source, nothing displays. – Antony D'Andrea Apr 25 '13 at 13:51
  • OK, I accidentally left a couple of curly brackets behind. Now that they have all gone. I am back with exactly the same state as before. I.e. the brackets make no difference. – Antony D'Andrea Apr 25 '13 at 13:53
  • Well, maybe it's the display? Maybe it's the code? Maybe you're just using this wrong? Maybe you inject a multipart mime sequence (which is broken / curtted) at a place where this is not supported? There can be thousand reasons based on what you (do not) provide in your question, so why worry so much? I was just giving you one hint from what was visible, however I didn't say that I understand what you do. So please bear with me just being helpful. I linked you the specs so that you can verify what I wrote. – hakre Apr 25 '13 at 13:53
  • I really am appreciating the help you are giving! I am just updating on progress. – Antony D'Andrea Apr 25 '13 at 13:55
0

Got it working! Turns out the extra line was not supposed to be there at all and was causing all sorts of problems. Managed to change some code so that it was not there and it all started working!

Antony D'Andrea
  • 991
  • 1
  • 16
  • 35