possible bug for attaching gpg keys?

classic Classic list List threaded Threaded
5 messages Options
Reply | Threaded
Open this post in threaded view
|

possible bug for attaching gpg keys?

John-657
Hi, in sqwebmail web interface we can attach our public key as an attachment and send to ourselves, but the source code of the sent mail starts the attachment as the following:

--=_0_72114_1335034659_000
Content-Type: application/pgp-keys; charset="utf-8"
Content-Transfer-Encoding: 7bit

-----BEGIN PGP PUBLIC KEY BLOCK-----
...

Note it missed the Content-Disposition part.  Ie, when attaching other normal files, that part should be:

--=_0_72369_1335034813_000
Content-Disposition: attachment;
  filename="123.doc"
Content-Type: application/octet-stream;
  name="123.doc"
Content-Transfer-Encoding: base64

Without the Content-Disposition part, other mail clients won't be able to display the attachment.

Attaching private key also has the same problem.


------------------------------------------------------------------------------
For Developers, A Lot Can Happen In A Second.
Boundary is the first to Know...and Tell You.
Monitor Your Applications in Ultra-Fine Resolution. Try it FREE!
http://p.sf.net/sfu/Boundary-d2dvs2
_______________________________________________
Courier-sqwebmail mailing list
[hidden email]
Unsubscribe: https://lists.sourceforge.net/lists/listinfo/courier-sqwebmail
Reply | Threaded
Open this post in threaded view
|

Re: possible bug for attaching gpg keys?

Sam Varshavchik
John writes:

> --=_0_72369_1335034813_000
> Content-Disposition: attachment;
>   filename="123.doc"
> Content-Type: application/octet-stream;
>   name="123.doc"
> Content-Transfer-Encoding: base64
>
> Without the Content-Disposition part, other mail clients won't be able to  
> display the attachment.

Although sqwebmail could include this field, this would be a bug in those  
other mail clients. As specified in RFC 2183:

"Content-Disposition is an optional header field. In its absence, the MUA  
may use whatever presentation method it deems suitable."

The Content-Type: header correctly specifies the MIME entity's type, and, as  
such, mail clients are certainly fully aware that this MIME entity contains  
a PGP key, and should know what to do with it. If the mail client has no  
specific understanding of a MIME entity that contains a PGP key, the default  
behavior would be to handle it as any other opaque, unknown, attachment.


------------------------------------------------------------------------------
For Developers, A Lot Can Happen In A Second.
Boundary is the first to Know...and Tell You.
Monitor Your Applications in Ultra-Fine Resolution. Try it FREE!
http://p.sf.net/sfu/Boundary-d2dvs2
_______________________________________________
Courier-sqwebmail mailing list
[hidden email]
Unsubscribe: https://lists.sourceforge.net/lists/listinfo/courier-sqwebmail

attachment0 (205 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: possible bug for attaching gpg keys?

John-657
In reply to this post by John-657



-----Original Message-----

>From: Sam Varshavchik <[hidden email]>
>Sent: Apr 21, 2012 7:02 PM
>To: [hidden email]
>Subject: Re: [sqwebmail] possible bug for attaching gpg keys?
>
>John writes:
>
>> --=_0_72369_1335034813_000
>> Content-Disposition: attachment;
>>   filename="123.doc"
>> Content-Type: application/octet-stream;
>>   name="123.doc"
>> Content-Transfer-Encoding: base64
>>
>> Without the Content-Disposition part, other mail clients won't be able to  
>> display the attachment.
>
>Although sqwebmail could include this field, this would be a bug in those  
>other mail clients. As specified in RFC 2183:
>
>"Content-Disposition is an optional header field. In its absence, the MUA  
>may use whatever presentation method it deems suitable."
>
>The Content-Type: header correctly specifies the MIME entity's type, and, as  
>such, mail clients are certainly fully aware that this MIME entity contains  
>a PGP key, and should know what to do with it. If the mail client has no  
>specific understanding of a MIME entity that contains a PGP key, the default  
>behavior would be to handle it as any other opaque, unknown, attachment.
>

The Content-Type part sqwebmail provided also doesn't have a name= field, so Thunderbird shows no attachment at all, people won't be able to know there is an attachment or be able to open/save it.  Is it possible for sqwebmail to include a name= field in its Content-Type there?  Or how would you advise Thunderbird users to import pgp keys from sqwebmail?  Thanks.

------------------------------------------------------------------------------
For Developers, A Lot Can Happen In A Second.
Boundary is the first to Know...and Tell You.
Monitor Your Applications in Ultra-Fine Resolution. Try it FREE!
http://p.sf.net/sfu/Boundary-d2dvs2
_______________________________________________
Courier-sqwebmail mailing list
[hidden email]
Unsubscribe: https://lists.sourceforge.net/lists/listinfo/courier-sqwebmail
Reply | Threaded
Open this post in threaded view
|

Re: possible bug for attaching gpg keys?

Sam Varshavchik
John writes:

> >"Content-Disposition is an optional header field. In its absence, the MUA
> >may use whatever presentation method it deems suitable."
> >
> >The Content-Type: header correctly specifies the MIME entity's type, and, as
> >such, mail clients are certainly fully aware that this MIME entity contains
> >a PGP key, and should know what to do with it. If the mail client has no
> >specific understanding of a MIME entity that contains a PGP key, the default
> >behavior would be to handle it as any other opaque, unknown, attachment.
> >
>
> The Content-Type part sqwebmail provided also doesn't have a name= field, so  
> Thunderbird shows no attachment at all, people won't be able to know there  
> is an attachment or be able to open/save it.  Is it possible for sqwebmail  
> to include a name= field in its Content-Type there?  Or how would you advise  
> Thunderbird users to import pgp keys from sqwebmail?  Thanks.
sqwebmail can certainly be changed to include the additional MIME metadata,  
of course.

However, again, this is a bug in Thunderbird, and should be reported as  
such. Sqwebmail, itself, should not have any issues with giving a meaningful  
user interface options, which includes supplying a default attachment name,  
if it were presented with a MIME entity that lacks those headers.

Did you report this as a bug in Thunderbird's Bugzilla? If not, why not?


------------------------------------------------------------------------------
For Developers, A Lot Can Happen In A Second.
Boundary is the first to Know...and Tell You.
Monitor Your Applications in Ultra-Fine Resolution. Try it FREE!
http://p.sf.net/sfu/Boundary-d2dvs2
_______________________________________________
Courier-sqwebmail mailing list
[hidden email]
Unsubscribe: https://lists.sourceforge.net/lists/listinfo/courier-sqwebmail

attachment0 (205 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: possible bug for attaching gpg keys?

John-657
In reply to this post by John-657



-----Original Message-----

>From: Sam Varshavchik <[hidden email]>
>Sent: Apr 21, 2012 9:52 PM
>To: [hidden email]
>Subject: Re: [sqwebmail] possible bug for attaching gpg keys?
>
>John writes:
>
>> >"Content-Disposition is an optional header field. In its absence, the MUA
>> >may use whatever presentation method it deems suitable."
>> >
>> >The Content-Type: header correctly specifies the MIME entity's type, and, as
>> >such, mail clients are certainly fully aware that this MIME entity contains
>> >a PGP key, and should know what to do with it. If the mail client has no
>> >specific understanding of a MIME entity that contains a PGP key, the default
>> >behavior would be to handle it as any other opaque, unknown, attachment.
>> >
>>
>> The Content-Type part sqwebmail provided also doesn't have a name= field, so  
>> Thunderbird shows no attachment at all, people won't be able to know there  
>> is an attachment or be able to open/save it.  Is it possible for sqwebmail  
>> to include a name= field in its Content-Type there?  Or how would you advise  
>> Thunderbird users to import pgp keys from sqwebmail?  Thanks.
>
>sqwebmail can certainly be changed to include the additional MIME metadata,  
>of course.
>
>However, again, this is a bug in Thunderbird, and should be reported as  
>such. Sqwebmail, itself, should not have any issues with giving a meaningful  
>user interface options, which includes supplying a default attachment name,  
>if it were presented with a MIME entity that lacks those headers.
>
>Did you report this as a bug in Thunderbird's Bugzilla? If not, why not?
>

I can indeed file at Thunderbird's Bugzilla, but that means to solve this problem I also have to file with Microsoft, because their Outlook doesn't know what this is and display as ATT00074.dat, so we need to educate users to manually name it as a .asc file when saved - or wait Microsoft to fix, which is next to impossible.  Furthermore, other email clients may have similar problem too, since as the current sqwebmail does when attaching other attachments, most modern email clients would expect more than a bare Content-Type without even a name= field.  When adding all these up, solving this problem calls for lots of management/support overhead.  I fully respect standard based software, but RFC is just recommendation for consideration, the reality can be quite otherwise.  Besides, adding name= doesn't violate RFC, it will only make sqwebmail more user friendly to broader user communities since that's what most email clients do.

That said, it's just my limited understanding.  I like the security history of sqwebmail, and hope it stays as secure as ever.  Software with broader user base tend to receive more audit as a side effect.

------------------------------------------------------------------------------
For Developers, A Lot Can Happen In A Second.
Boundary is the first to Know...and Tell You.
Monitor Your Applications in Ultra-Fine Resolution. Try it FREE!
http://p.sf.net/sfu/Boundary-d2dvs2
_______________________________________________
Courier-sqwebmail mailing list
[hidden email]
Unsubscribe: https://lists.sourceforge.net/lists/listinfo/courier-sqwebmail