Mikel Lindsaar
11/4/2007 11:46:00 PM
> > Content-Transfer-Encoding: Base64
>
> This was caused by some code like:
>
> incoming = TMail::Mail.parse($stdin.read)
> outgoing = TMail::Mail.new
>
> outgoing.transfer_encoding = incoming.transfer_encoding
> outgoing.body = incoming.body
>
> I assume that's because TMail is undoing the Base64 encoding for me
> and not putting it back to match the transfer_encoding() of
> outgoing. Do I have that right?
TMail does not handle the email body. In fact, it basically ignores
it beyond breaking it down by parts when you explicitly request it.
So this is what happens:
mail = TMail::Mail.load("my_base64_encoded_body_email")
body = mail.body # this will actually decode the body for you to be nice
mail.body = body # change the body text to an unencoded string
mail['Content-Transfer-Encoding'] == Base64 # => true
Basically, TMail has no way of knowning that the body text has changed
to a non Base64 string, it needs to be told that.
I *think*, in essence, this is what is happening on the gateway,
please correct me if I am wrong.
An (easier?) way, that preserves the body text and the transfer
encoding type would be to do:
outgoing_mail = TMail.parse($stdin.read)
outgoing_mail['x-header'] = "whatever you need to add"
Because when you do the outgoing.body = incomming.body TMail is being
nice and decoding it for you.
If you want the undecoded text and still do the assignment, you can do:
outgoingmail.body = incommingmail.quoted_body
I think I might make an alias for "undecoded_body" to "quoted_body" but anyway.
Is there any reason you are making two TMail objects instead of just
making one new one and parsing in the incomming string and then adding
what you need?
> What's the best way for us to fix this? Should I not copy the
> transfer encoding of the original message? Will TMail normalize all
> of them for me? What does it normalize to? Maybe I should declare
> that.
Just make one object and pull in the data and leave the body alone, I
think, would be the easiest.
> Mikel, why is TMail not wrapping this? I know you added some checks
> to ignore X-* headers, but shouldn't it only ignore them if they
> aren't easily wrapped? This one has a lot of whitespace in it, so
> it's wrappable, right?
Hmm... I originally put in stuff to ignore the X-Headers completely,
this smelt a bit bad so then I changed this to wrapping anything that
has over 78 characters total that has a whitespace which is more RFC
compliant.
So, now it doesn't ignore any headers... it tries to wrap them if they
have whitespace that it can wrap (ie, whitespace in the first 78
characters). If it doesn't have whitespace within the first 78 chars
(including the header) it doesn't wrap....
So, basically, this should be wrapping correctly.
But I am pretty sure you are using this version of trunk because that
is the same revision that fixed the reply-to problem you were having.
Could you send me an unencoded, unwrapped copy of the string you
insert so I can make a test case with it?
Regards
Mikel