No Voicemail Attachment on Mac Mail?

Posts: 656 · Posted: Mon Oct 27, 2008 12:44 pm Post subject:

Are you looking at a voicemail notification received prior to my posting.? The change was rolled back after 1PM EST. You will be able to play the message as you did before on notifications received in current time. Please leave yourself a voicemail to test and let me know if you still do not see the attachment as you did prior to a week ago.

Posts: 3 · New Forum Member Joined: Oct 25, 2008 Posts: 3

It works again! Fantastic! Thanks. I did not test it before making the last post. It is 1:07 CST here. It works both in Mail and on the iPhone as before.

Thanks again.

VonTechMgr wrote:

Are you looking at a voicemail notification received prior to my posting.? The change was rolled back after 1PM EST. You will be able to play the message as you did before on notifications received in current time. Please leave yourself a voicemail to test and let me know if you still do not see the attachment as your did prior to a week ago.

Posts: 3 · New Forum Member Joined: Oct 23, 2008 Posts: 3

It's working fine now! Thanks!

Posts: 3 · New Forum Member Joined: Oct 25, 2008 Posts: 3

Although I haven't yet tested the "roll-back" fix, I was wondering if you could provide some detail on the change that was made.

I agree with your general comment that if it is in the SPEC it should be supported by Apple in Mail.app. Thank you for accommodating us with the rollback.

If we need to open a ticket with Apple about this, what part of the header needed to be changed back to support Mail.app?

Thanks,

Josh

Posts: 2 · New Forum Member Joined: Oct 27, 2008 Posts: 2

VonTechMgr wrote:

While you are correct that there was change made on the Vonage side which did change the headers, this change is well with spec of the RFC. It is an issue of how the application interprets the header and is technically a Mac issue and is why other mail applications were unaffected.

Oh yes, I do agree that the Apple Mail application needs an update to be able to handle the new headers. I only noticed this flaw because of Vonage's recent change in the email header format as I mentioned. I've checked other messages I've received that contain attachments and I haven't identified any yet which utilize the new header format. So while the new headers are within spec of the RFC they don't seem to be widely used yet based on my limited sample.

Thanks for the quick response and the rollback to the previous header format. This sort of responsiveness is a BIG reason why I favor Vonage over one of the larger, faceless communication companies.

Jeff

Posts: 3 · New Forum Member Joined: Oct 25, 2008 Posts: 3

Have a look at the MIME RFC sections regarding Mulitpart subtypes:

http://en.wikipedia.org/wiki/MIME#Mixed

Mixed
Multipart/mixed is used for sending files with different "Content-Type" headers inline (or as attachments). If sending pictures or other easily readable files, most mail clients will display them inline (unless otherwise specified with the "Content-disposition" header). Otherwise it will offer them as attachments. The default content-type for each part is "text/plain".
Defined in RFC 2046, Section 5.1.3

The best question to ask now is why did your team make the change? Is there a need for this change? Was this an oversight. Was it not fully QA'd? Will this happen again in the future?

Posts: 656 · Posted: Mon Oct 27, 2008 5:39 pm Post subject:

It was not my team that implemented the change. The change to the header was not by purposely done by design but is part of a vendor upgrade that is to provide greater internal support and expansion. While everything is QA'd before deployment, it is not possible to test each and every piece of hardware and software application there is before rolling out into production. In this case, it was most likely not QA'd against Mac Mail or iPHONE. It was properly QA'd and worked as an attachment should inside any other standard mail application which is good enough for it to pass.

After it was reported by the customers, the Dev team evaluated and found the issue was with Mac, not with the header and decided to roll back for customer satisfaction. To implement the same upgrade, they are adjusting the code so that it will not affect the Mac attachments again.