My mobile phone provider here is sunrise. I am subscribed to what they call “Onebox”, a unified messageing solution.
I did that because I have access to my voice mailbox via their web-interface which is much more comfortable (and cheaper) than to use the mobile phone.
Unfortunately, their interface does not allow forwarding those messages to another address. While they say they do, entering a forwarding-address actually forwards the emails sent to the sunrise mailbox, but the voice messages stay where they are.
Today I though about accessing the box via fetchmail and sending it to my regular mailbox.
While this turned out to work extremely well (even the simple notification flag gets cleard on my handset when the fetchmail job forwards the message), the protocol the server speaks is awfully strange. It’s supposed to be POP3 passing around RFC2822 messages, it’s actually something else… Just have a look:
pilif@galadriel ~ % telnet um.sunrise.ch pop3 Trying 220.127.116.11... Connected to um.sunrise.ch. Escape character is '^]'. 1 +OK POP3 umsi3-c04d2.mysunrise.ch vUMSI v18.104.22.168 (UM2 Build 030408) server ready 2 user [phonenumber] 3 +OK User name accepted, password please 4 pass [password] 5 +OK Mailbox open, 1 messages 6 stat 7 +OK 1 192931 8 retr 1 9 +OK 1421099 octets 10 From: [calling number] <[calling number]@mysunrise.ch> 11 To: - <[phonenumber]@mysunrise.ch> 12 Date: 04 Oct 2004 09:29 +0200 13 Message-id: 0xe97d4b80-0x40-0x3735-0x50 14 Subject: Voice Message 15 Mime-Version: 1.0 (Voice Version 2.0) 16 Content-Type: multipart/voice-message; 17 boundary="2448314160_4000_141330_5000.04102004_0929" 18 Sensitivity: Normal 19 Importance: Normal 20 X-Priebity: 1 (Highest) 21 Content-Duration: 64 22 X-UMSI-Transferred: Server-Id="1"; Server-Type="INFINITY"; 23 Profile="[phonenumber]@4:6"; 24 Original-Message-UID="244831416 004 005 14133"
(I’ve added the line numbers myself)
Line 7: Oh nice. There’s a message and it’s about 188 KiB large
Line 9: Wait a minute… 1300 KiB? Didn’t they say otherwise in Line 7? Actually it’s the server decompressing the Voice message and converting it to WAV just after the retr
Line 13: Is that supposed to be a valid Message-ID? Don’t think so
Line 15: What’s that? That’s not a valid Mime-Version Header
Line 18+19: Are those really valid message headers?
Line 21: What the heck is “Priebity”? That’s not an english word.. Maybe they mean “Priority”?
Line 22: Is this a valid header?
I pity the developers of mail user agents: They must cope with such rubbish and in the end, they are blamed if they do not. It’s never the vendors of the brolen servers because those are not visible to the end users.
Different question: Why is it always closed source commercial software doing such stupid things? They get paid to create working software and what you see above is not what I’d call “working”.
When I’m writing software communicating with some other component not written by me, I follow the defined protocol to the character whether the software is going to be publically released or not. It’s just polite.