Submit Hint Search The Forums LinksStatsPollsHeadlinesRSS
14,000 hints and counting!


Click here to return to the 'It's a bug, of course.' hint
The following comments are owned by whoever posted them. This site is not responsible for what they say.
It's a bug, of course.
Authored by: osxpounder on Oct 21, '04 02:58:47PM

If you drag an attachment into your Mail, and there is text after it, and that text becomes separated somehow on the receiving end, then ... it's a bug. The technical reasons why and wherefore don't matter. What matters is the result.

I work with a lot of PC users, and our office uses GroupWise. I found that unless I put attachments after all the text, GroupWise users would not receive anything after the attachment. It would look, to them, as if my attachment was the last thing in my message.

That's a bug. No one should have to learn or remember to treat Mail differently because it handles attachments differently. If you drag an attachment into your Mail, doing so shouldn't interfere with the text of your message, for any reason, ever. They are called attachments because they are supposed to be attached, not included, enclosed, mixed in, or anything else other than attached. They are supposed to attach to an email, not interfere with that email in any way.

---
--
osxpounder



[ Reply to This | # ]
Supporting standards...
Authored by: MattHaffner on Oct 23, '04 11:00:45PM

"That's a bug."

In the recipients' mail client(s), which probably claim(s) to be MIME compliant. Yes.

MIME is simple. A client that is not supporting multipart MIME or that supports it in a way that only displays the text of the first text part is the buggy part of the connection here. Not Mail.app.

In the case of a e-mail with a graphical element "attached" in the middle, there is nothing special about the 1st or 3rd (or any) text parts. They should be displayed (or offered to be displayed), on-screen in any mail client that conforms to the MIME *standard* (RFC-2049). What happens to the 2nd, non-text part is completely up to the client, although it has to at least notify the user that it exists (and should probably be able to at least save it).

The notion of an "attachment" coming at the end of a message is one based on our history of using text-based e-mail clients. The underlying standard that encodes them doesn't have that barrier, however. Any modern e-mail client shouldn't either.



[ Reply to This | # ]