views:

796

answers:

7

I have created aand sent a short email with a .txt attachment in an iPhone app.

  1. If the attachment is about 10 lines long, GMail opens it just fine.

  2. If it's more than 20 or so lines, GMail chokes - it won't open the attachment, download the attachment, or even forward the email.

  3. Also, if I send the same email to my colleague and he opens it with his Mac OS Mail client, everything works fine.

For example, the following is the content of the text file (this length will open in GMail just fine):

ACCELEROMETER READINGS
-0.0724487,-0.941833,-0.235458,2009-07-11 15:18:46 -0700
-0.0724487,-0.941833,-0.271683,2009-07-11 15:18:47 -0700
-0.0724487,-0.923721,-0.253571,2009-07-11 15:18:48 -0700
-0.0543365,-0.923721,-0.326019,2009-07-11 15:18:49 -0700
-0.0724487,-0.959946,-0.181122,2009-07-11 15:18:50 -0700
-0.0543365,-0.923721,-0.253571,2009-07-11 15:18:51 -0700
-0.108673,-0.923721,-0.380356,2009-07-11 15:18:52 -0700
-0.0724487,-0.923721,-0.271683,2009-07-11 15:18:53 -0700

GPS READINGS

HEADING READINGS
211.421,2009-07-11 15:18:46 -0700
206.421,2009-07-11 15:18:49 -0700
184.421,2009-07-11 15:18:50 -0700
195.421,2009-07-11 15:18:51 -0700
198.421,2009-07-11 15:18:53 -0700

If the file is twice this size, GMail can't deal ith it, but once again Mail can. So, what might be the problem? I created the email as follows:

SKPSMTPMessage *testMsg = [[SKPSMTPMessage alloc] init];
testMsg.fromEmail = @"[email protected]";
testMsg.toEmail = @"[email protected]";
testMsg.relayHost = @"smtp3.webfaction.com";
testMsg.requiresAuth = YES;
testMsg.login = @"andrewljohnson";
testMsg.pass = @"********";
testMsg.subject = @"iPhone Instrument Readings";
testMsg.wantsSecure = YES; // smtp.gmail.com doesn't work without TLS!
testMsg.delegate = self;

NSDictionary *plainPart = [NSDictionary dictionaryWithObjectsAndKeys:@"text/plain",kSKPSMTPPartContentTypeKey, @"Hey Kevin,\nHere are some GPS readings for you to filter.\n\nLove, \nTrailBehind",kSKPSMTPPartMessageKey,@"8bit",kSKPSMTPPartContentTransferEncodingKey,nil];
NSData *fileData = [NSData dataWithContentsOfFile:fileName];    
NSDictionary *attached = [NSDictionary dictionaryWithObjectsAndKeys:@"text/directory;\r\n\tx-unix-mode=0644;\r\n\tname=\"readings.txt\"",kSKPSMTPPartContentTypeKey, @"attachment;\r\n\tfilename=\"readings.txt\"",kSKPSMTPPartContentDispositionKey,[fileData encodeBase64ForData],kSKPSMTPPartMessageKey,@"base64",kSKPSMTPPartContentTransferEncodingKey,nil];

testMsg.parts = [NSArray arrayWithObjects:plainPart,attached,nil];
[testMsg send];
+1  A: 

I suggest you use WireShark to see exactly what is being sent when you send the message. Then use a normal mail client to send the same message (again to GMail) and see what the difference is - as well as whether the attachment can then be downloaded.

My guess is that there's something not-quite-compliant about the way you're sending the message, which GMail is complaining about but your friend's SMTP server isn't. It's likely to be more to do with the server than the receiving client, IMO.

Another thing to try is hooking up an IMAP client to your GMail account - can you get the attachment then?

Jon Skeet
+1  A: 

I'm the friend - I use pop.gmail.com to get incoming mail and smtp.gmail.com for outgoing mail via Mail for Mac OS X.

Tim Bowen
A: 

Have you considered uploading the data to a server and then providing the user a link to the file in an email? I know that would be a pretty substantial shift from your current approach, and it requires having a server - but I imagine GPS and accelerometer history files could get pretty large and as a user I wouldn't want them clogging up my inbox!

It might be the best way to get around problems with large attachments, too - I know the attachment size cap varies by email host, but at my school it's like 4MB...

Good luck!

Ben Gotow
That's a reasonable idea. This isn't really for real users though. My colleague just needs some dumps of data to work on a Kalman Filter, then everything will be local and saved out as GPX, for export via different mechanisms.
Andrew Johnson
A: 

Basically, your MIME attachment is suspect. Get the MIME spec and double check against that. If i recall correctly, you shouldn't have the \r\n after a semi-colon, as CRNL has a specific delimitation meaning. I haven't looked at the MIME spec in a while so you might be okay. It's just where I would start.

Try attaching as a plaintext file instead of file in a directory in an attachment. Also, it's weird to me that your directory name has a .txt suffix. I wonder if that's confusing for the rx mail server.

Remember, that every mail server has different levels of fidelity with regard to which attachments is can parse. You might end up having to work around their limitations.

Kailoa Kadano
A: 

A mime is a terrible thing to waste.

jbrennan
A: 

I still think the problem is that you have your attachment marked with the MIME type "text/directory", which is a type defined for passing around email contact lists. (See RFC)

So I bet what's happening is that some email clients are treating a .txt attachment with a text/directory MIME type as a plain text file, and some are trying to do something crazy to it thinking your list of GPS coordinates is really a set of phone numbers or something.

So try changing "text/directory" to "text/plain"!

David Maymudes
Already tried that, thanks.
Andrew Johnson
+1  A: 

You're using [fileData encodeBase64ForData] but I see there's also a function called encodeBase64ForDataWrapped which adds line breaks. Perhaps you should be calling that instead, and if your attachment is sufficiently long the long base64 line is confusing somebody.

David Maymudes
That function seems to be undefined and I can't find anything about it on Google.
Andrew Johnson
I found it looking in the newest version of the SKPSMTP source code.
David Maymudes
Oops, yeah, I found it now... it's actually encodeWrappedBase64ForData, and it works like a charm!
Andrew Johnson
sorry about the mistranscription, glad your search is over.
David Maymudes