361253 - Support alternative encoding methods (binhex, uuencode, etc.)

Status: RESOLVED WONTFIX

(Penelope Graveyard :: General, defect, P5)

Description

[iraruben]

User-Agent:       Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.8.1) Gecko/20061010 Firefox/2.0
Build Identifier: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.8.1) Gecko/20061010 Firefox/2.0

If there is NOT a platform independent method of encoding then support alternative methods functionally like current Eudora does.  At least allow Mac machines to send messages and enclosures so that they can be read/expanded on Windows machines.

Reproducible: Always

Steps to Reproduce:
On a Mac take some file like a pdf and add it to a email.
Send to someone who uses Windows.
See if they can read it.

Actual Results:  
If memory serves, it's been a while, Eudora's AppleSingle encoding appears to work  sending data to Windows machines.

Expected Results:  
I expect the receiver to read my mail and enclosures no matter which platform they are on.

Comment 1

[Matt Dudziak]

(In reply to comment #0)
> User-Agent:       Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US;
> rv:1.8.1) Gecko/20061010 Firefox/2.0
> Build Identifier: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US;
> rv:1.8.1) Gecko/20061010 Firefox/2.0
> 
> If there is NOT a platform independent method of encoding then support
> alternative methods functionally like current Eudora does.  At least allow Mac
> machines to send messages and enclosures so that they can be read/expanded on
> Windows machines.
> 
> Reproducible: Always
> 
> Steps to Reproduce:
> On a Mac take some file like a pdf and add it to a email.
> Send to someone who uses Windows.
> See if they can read it.
> 
> Actual Results:  
> If memory serves, it's been a while, Eudora's AppleSingle encoding appears to
> work  sending data to Windows machines.
> 
> Expected Results:  
> I expect the receiver to read my mail and enclosures no matter which platform
> they are on.
> 

Are you experiencing any troubles sending/receiving attachments using Thunderbird? If so, please give specific examples and attach examples to this bug. 

This bug will remain unconfirmed and eventually be closed unless there is a specific report of attachment problems using Thunderbird (and ultimately Penelope).

Comment 2

[iraruben]

> Are you experiencing any troubles sending/receiving attachments using
> Thunderbird? If so, please give specific examples and attach examples to this
> bug. 
> 
> This bug will remain unconfirmed and eventually be closed unless there is a
> specific report of attachment problems using Thunderbird (and ultimately
> Penelope).

I was given the impression that we should add suggestions for Penelope that we like to see from Eudora, not TB.  I don't use TB, I use Eudora.  I have no idea whether Mac TB has problems sending enclosures to Windows users using ANY emailer of their choice, not just TB.

If Macintosh TB users have NO PROBLEMS sending emails AND enclosures (.sit, .sitx, .pdf's, etc.) to Windows users using any of their exiting emailers, then fine, so long as that functionality is inherited into Penelope.  I only submitted this report/suggestion to make sure such functionality does not slip through the cracks in Penelope.

I suggest the way to reproduce this is take a .sit and .pdf file created on a Mac and send it to a Windows machine NOT using TB and see if everything comes through ok.  If you want to use TB on the Mac side, ok.

Comment 3

[Joseph W Donahue]

Well this IS a Eudora feature request. But I would be surprised if it isn't already dealt with in Thunderbird and if it isn't it would be a bug in my book and therefore a Thunderbird bug that should be handled there.  There are going to be some Eudora features that make no sense at all in Penelope simply because Penelope is based on Thunderbird.  

Comment 4

[iraruben]

> But I would be surprised if it isn't already dealt with in Thunderbird...

As best as I can tell, after firing up TB2.0b1, it isn't.  I looked through all the various options, menus, preferences, etc.  I see nothing that addresses this feature while composing email and/or attachments.

Comment 5

[iraruben]

> But I would be surprised if it isn't already dealt with in Thunderbird...

As best as I can tell, after firing up TB2.0b1, it isn't.  I looked through all the various options, menus, preferences, etc.  I see nothing that addresses this feature while composing email and/or attachments.

Comment 6

[iraruben]

It would be nice if this bug system gabe me some kind of visual confirmation that the message was actually committed.  Sorry for the double post.  Is there any way to delete the duplicate?

Comment 7

[Gib Henry]

Aren't these handled by system components or third-party utilities?

Comment 8

[iraruben]

For formats that are supported on both the sender's and receiver's platforms, like PDF, you should not have to expect the recipient to have to do any extra work to view the enclosure.  They might not even know that they need to use some additional application nor how to use it nor want to do the additional work even if they know it exists.  

Even formats that do require an additional utility, like compressed files such a Stuffit, need to be received in the format appropriate to the platform so that the additional utility can read it correctly.

Comment 9

[Lint Hasenpfeffer]

I wanted to jump in here as I am wholly confused on reading this. Unless I'm mistaken, the default encoding for all attachments is MIME/b64. Any other encoding scheme is obsolete (uuencode)  and IMHO should be avoided. If memory serves, 'AppleDouble' was a method for sending old Mac OS files with resource forks intact, to another Mac OS user, however the actually attachement(s) was MIME, and the reconsution of the 2 forks occured as a system function or as handwaving of the application.

As a side note, I had some windows users who somehow changed eudora to send binhex attachements, which ended up botched on the receivers end, seems like a feature that had no reason to be.

Comment 10

[iraruben]

I'll say it again, from real world experience, attempting to send from a Mac machine to a windows machine does not work when using "standard" (?) binhex encoding.  This may be consistent with what you say about "users who somehow changed eudora to send binhex attachements, which ended up botched on the receivers end".  I don't know what windows emailers expect for their encoding but apparently it isn't that "standard" (for me using eudora's AppleSingle seems to pass attachments successfully through to windows receivers).  Either that or it differs among different email programs.  So the flexibility on the *senders* end is needed.  It may be nice to impose a standard common encoding but you can't insist that the receivers use it and you can't expect them all to be using eudora.

Comment 11

[Lint Hasenpfeffer]

Ok well firstly, binhex isn't a standard. The only standard currently in use is MIME. Binhex should only be used if you know the receiving end can process binhex, and then use the subsequent decoded dual forked file. Your request for flexibility seems to be contradictory, because using anything other than MIME, isn't guaranteed to work. In the end, Binhex should not be used. If you must send a binhex file, encode it first and then let the mailer send it as a MIME attachment.

And yes, I'm sorry you can in fact impose a standard and insist that receivers use it, thats why its a standard. If you want to write an email program that only accepts rot13, to use a ridiculous example well then you likely wont get a lot of interoperability. uuencode and binhex are effectively defunct, and things like yenc are not standard. In short, MIME is it. That much being said, I am very curious about the problems you have using apple double/mime and your assertion that apple single is seemingly the only thing that works. Try and get a hold of me, I'd like to see what you are actually sending.

Comment 12

[Matt Dudziak]

(In reply to comment #10)
> I'll say it again, from real world experience, attempting to send from a Mac
> machine to a windows machine does not work when using "standard" (?) binhex
> encoding.  

Have you seen this problem when using Eudora 8 (Penelope /  Thunderbird) to send the attachments? We are no longer working on the old Eudora, and the source code for the new Eudora is completely different. I'd hate for us to waste time when there is no problem to solve.

If you can give us examples of where the NEW Eudora is failing to send an attachment correctly, please do.

Thanks, Matt

Comment 13

[Matt Dudziak]

Seeing as we have no examples of a need for this, I am going to mark this resolved:wontfix. If a need arises we can open a new bug.