Michael Fox
2017-09-25 17:46:01 UTC
I have what is probably an unusual problem to solve. I'm willing to do the
work to solve it. But as someone new to MIMEDefang in particular and MIME
details in general, I want to first get a sanity check to see if what I'd
like to do is reasonably possible, and then see if perhaps parts of the
problem have already been solved by others.
Problem:
I have hundreds of old (but necessary) email clients that only understand
plain text. They can accept a single-part MIME text/plain message, I think
because they just ignore the header. (For the curious, these are amateur
radio BBS systems that speak SMTP, but were developed before MIME existed.
They still have relevance/usefulness for communications in the field,
especially emergency communications over great distances).
I'd like to be able to deliver HTML and Base64 messages to those clients.
Already Solved:
I'm using the built-in remove_redundant_html_parts() function and it works
great, where that situation applies.
Yet to Be Solved/Can this be Solved?:
I'd like be able to deal with text-to-email. For example, Sprint takes a
basic ascii-text message, wraps it in html, and then base64-encodes it prior
to sending. The recipient receives a single-part mime message with
Content-Type of text/html; charset="UTF-8", and Content-Transfer-Encoding of
base64.
I think what would need to be done is to decode the base64, which would
result in plain html (not a multi-part html with redundant plain text), and
then strip the extra html. I'd love to be able to do both steps. But even
decoding base64 to the underlying html would make the message readable by a
human. And, being new to MIMEDefang, I don't know if this type of pipeline
processing of a single mime part is viable. It's certainly different than
just throwing away redundant parts.
So, is this something that's in the realm of reasonable for MIMEDefang to
handle? If so, would I need to start from scratch? Or, do at least parts
of the solution exists somewhere?
Thanks in advance,
Michael
_______________________________________________
NOTE: If there is a disclaimer or other legal boilerplate in the above
message, it is NULL AND VOID. You may ignore it.
Visit http://www.mimedefang.org and http://www.roaringpenguin.com
MIMEDefang mailing list ***@lists.roaringpenguin.com
http://lists.roaringpeng
work to solve it. But as someone new to MIMEDefang in particular and MIME
details in general, I want to first get a sanity check to see if what I'd
like to do is reasonably possible, and then see if perhaps parts of the
problem have already been solved by others.
Problem:
I have hundreds of old (but necessary) email clients that only understand
plain text. They can accept a single-part MIME text/plain message, I think
because they just ignore the header. (For the curious, these are amateur
radio BBS systems that speak SMTP, but were developed before MIME existed.
They still have relevance/usefulness for communications in the field,
especially emergency communications over great distances).
I'd like to be able to deliver HTML and Base64 messages to those clients.
Already Solved:
I'm using the built-in remove_redundant_html_parts() function and it works
great, where that situation applies.
Yet to Be Solved/Can this be Solved?:
I'd like be able to deal with text-to-email. For example, Sprint takes a
basic ascii-text message, wraps it in html, and then base64-encodes it prior
to sending. The recipient receives a single-part mime message with
Content-Type of text/html; charset="UTF-8", and Content-Transfer-Encoding of
base64.
I think what would need to be done is to decode the base64, which would
result in plain html (not a multi-part html with redundant plain text), and
then strip the extra html. I'd love to be able to do both steps. But even
decoding base64 to the underlying html would make the message readable by a
human. And, being new to MIMEDefang, I don't know if this type of pipeline
processing of a single mime part is viable. It's certainly different than
just throwing away redundant parts.
So, is this something that's in the realm of reasonable for MIMEDefang to
handle? If so, would I need to start from scratch? Or, do at least parts
of the solution exists somewhere?
Thanks in advance,
Michael
_______________________________________________
NOTE: If there is a disclaimer or other legal boilerplate in the above
message, it is NULL AND VOID. You may ignore it.
Visit http://www.mimedefang.org and http://www.roaringpenguin.com
MIMEDefang mailing list ***@lists.roaringpenguin.com
http://lists.roaringpeng