Why is this successfully sent attached file called "noname"?

[Nels Nelson]

For a while, I was having trouble getting this to work at all, but I can now confirm that the e-mail does indeed get sent successfully, and the file is being attached.

However, the name of the file is incorrect.

Why is the attachment called, only "noname" when I receive the e-mail?

https://gist.github.com/nelsnelson/b7420287a85d82ec1ce2

I would have expected that the

    basename = File.basename attachment
    :attachments => { basename => content }

bit would have been sufficient for naming the attachment.

Best regards,
-Nels

[Nels Nelson]

By the way, the headers on the original message look like this:

----==_mimepart_5487edb57b890_357f7d0986fc
Content-Type: text/plain;
 charset=UTF-8
Content-Transfer-Encoding: 7bit

test
----==_mimepart_5487edb57b890_357f7d0986fc
Content-Type: application/gzip;
 charset=UTF-8;
 filename= test.dump.gz
Content-Transfer-Encoding: base64
Content-Disposition: attachment;
 filename= test.dump.gz
Content-ID: <test.d...@sol.local>

H4sIAAAAAAAA/7ycCT<snip>

Yet the attachment still shows up with the name "noname".

I'm explicitly compressing the test.dump file with zlib.

[Nels Nelson]

Looking at it closer, here are the headers used when GMail sends an e-mail with the same file attached:

    Content-Type: application/x-gzip; name="test.dump.gz"

    Content-Disposition: attachment; filename="test.dump.gz"

    Content-Transfer-Encoding: base64

    X-Attachment-Id: f_i3idtije0

And when pony does it:

    Content-Type: application/gzip;
     charset=UTF-8;
     filename=test.dump.gz.gz
    Content-Transfer-Encoding: base64
    Content-Disposition: attachment;
     filename=test.dump.gz.gz
    Content-ID: <test.du...@sol.local>

Clearly, pony is using the "filename" attribute twice, both in Content-Type and also in Content-Disposition.  Whereas, GMail uses the "name" attribute in Content-Type.  I doubt that the quotes or lack thereof in the pony example have much to do with anything.

By the way, I tried manually adding a X-Attachment-Id header with a SecureRandom.hex[0..11] into the :headers hash for the Pony.mail options to see if there was some sort of identifier requirement, but as we can see, it is missing, so I can't discount that as a possible cause for the "noname" syndrome.

[Ben Prew]

Thanks Nels, I'll take a look and see what I can come up with.

--

---
You received this message because you are subscribed to the Google Groups "Ponyrb" group.
To unsubscribe from this group and stop receiving emails from it, send an email to ponyrb+un...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Nels Nelson]

Hi Ben.

I decided that there must have been something wrong with the ruby mail gem, so I started monkey-patching the crap out of the Mail module stuff, and trying to force the attachment headers to look exactly like the headers in an e-mail sent from GMail.  Here are those efforts:

https://gist.github.com/nelsnelson/bbe061dd34896fe5cc60

But the file still winds up being called "noname" in GMail.  This leads me to believe that there might be something wrong with the GMail software.

The only thing I didn't try to change is the multipart Content-Transfer-Encoding which appears to be 7bit, but does not appear to be specified in a GMail-sent e-mail.

E-mail sent from GMail:

    MIME-Version: 1.0

    Received: by 10.50.232.39 with HTTP; Wed, 10 Dec 2014 22:34:58 -0800 (PST)

    Date: Thu, 11 Dec 2014 00:34:58 -0600

    Delivered-To: em...@gmail.com

    Message-ID: <CABfJtPv6CFPDo7Qru+QPvAwJ...@mail.gmail.com>

    Subject: backup

    From: Nels Nelson <email@gmail.com>

    To: Nels Nelson <email@gmail.com>

    Content-Type: multipart/mixed; boundary=001a11449aa2a67f9a0509eaf9dd

    --001a11449aa2a67f9a0509eaf9dd

    Content-Type: multipart/alternative; boundary=001a11449aa2a67f790509eaf9db

    --001a11449aa2a67f790509eaf9db

    Content-Type: text/plain; charset=UTF-8

    backup

    --001a11449aa2a67f790509eaf9db

    Content-Type: text/html; charset=UTF-8

    <div dir="ltr">backup</div>

    --001a11449aa2a67f790509eaf9db--

    --001a11449aa2a67f9a0509eaf9dd

    Content-Type: application/x-gzip; name="test.dump.gz"

    Content-Disposition: attachment; filename="test.dump.gz"

    Content-Transfer-Encoding: base64

    X-Attachment-Id: f_i3jr40e50

E-mail sent from pony with mail monkey-patches:

    To: em...@gmail.com

    Message-ID: <5488c9bed4e40...@phoenix.mail>

    Subject: backup

    Mime-Version: 1.0

    Content-Type: multipart/mixed

    Content-Transfer-Encoding: 7bit

    Content-Disposition: attachment

    X-Attachment-Id: 94f4c08b6da

    ----==_mimepart_5488c9be68fb0_471f7ee7905c

    Content-Type: multipart/alternative; boundary="--==_mimepart_5488c9be635d8_471f7ee78980"; charset=UTF-8

    Content-Transfer-Encoding: 7bit

    ----==_mimepart_5488c9be635d8_471f7ee78980

    Content-Type: text/plain; charset=UTF-8

    Content-Transfer-Encoding: 7bit

    backup

    ----==_mimepart_5488c9be635d8_471f7ee78980

    Content-Type: text/html; charset=UTF-8

    Content-Transfer-Encoding: quoted-printable

    backup=

    ----==_mimepart_5488c9be635d8_471f7ee78980--

    ----==_mimepart_5488c9be68fb0_471f7ee7905c

    Content-Type: application/x-gzip; name="test.dump.gz"

    Content-Transfer-Encoding: base64

    Content-Disposition: attachment; filename="test.dump.gz"

    Content-ID: <test.dump.gz@phoenix>

    X-Attachment-Id: f_9d9647c21

I guess I could try eliminating the Content-ID header.  I doubt that would make a difference, though.

[Ben Prew]

Nels,

Thanks for working on this.  Your latest example looks almost identical to the Gmail example you provided earlier, I don't know why Gmail would list attachements as "noname" in that case.

This SO question implies that it could be an encoding issue:

http://stackoverflow.com/questions/11408468/attached-file-in-gmail-has-the-name-noname

Maybe it's the mixed Content-Transfer-Encodings?  (your example has 7-bit in the global headers and base64 in the attachment heads)

Thanks

--