Has anyone else experienced this?

When I send a message to support@kace.com (either to start a new ticket or to update an existing one), if I send any attachment(s), the attachment(s) does not get added to the ticket.

This happens to our own KBox as well if an end user sends an attachment when they send a message to our support address. It is very embarrassing to have to ask our end-users to re-send the attachment to our individual e-mail addresses.

djz
0 Comments   [ + ] Show Comments

Comments

Please log in to comment

Rating comments in this legacy AppDeploy message board thread won't reorder them,
so that the conversation will remain readable.

Answers

0
How big is the attachment? I remember sending an attachment that was too large I think over 5MB that it kicked back at one time. Since then I make sure to zip up any attachments.
Answered 11/07/2011 by: darkhawktman
Green Belt

Please log in to comment
0
Kbox doesn't have a size limit or attachment restrictions on mail, but your internal mail client/server might. Can you add the same attachment through the UI?
Answered 11/07/2011 by: cblake
Red Belt

Please log in to comment
0
It doesn't seem to matter what size or type of attachment, but I'll try testing with a .zip file to see if it accepts those.
djz
Answered 11/08/2011 by: zookdj
Second Degree Blue Belt

Please log in to comment
0
@darkhaktman: I tested an attachment that was 4 kb in size (a zip file), and it still wouldn't reach the KACE support web site. Just the body of the message is posted.

@cblake: Yes, I can add the same attachment through the UI. I can also confirm by viewing our mail server logs that our mail server is not removing the attachment before sending it on. The KBox just drops the attachment.

Note: this only happens when a non-owner sends the message. An owner can send messages with attachments and the attachments are kept.

djz
Answered 11/08/2011 by: zookdj
Second Degree Blue Belt

Please log in to comment
0
Hmmm not sure what I ran into then. I know that we have a 10MB limit on attachments but I haven't sent anything to Kace over that limit when I had the failure.
Answered 11/08/2011 by: darkhawktman
Green Belt

Please log in to comment
0
I picked up zookdj's ticket that he submitted and fixed the issue.

I opened a bug / enhancement to resolve it on customer's kboxes.

The issue was that his email attachments did not have a "name" parameter. Some email systems do this despite it not being recommended by RFC. You may be able to find a solution within your mail software if you cannot wait for a kbox upgrade, or contact support.
Answered 11/10/2011 by: GillySpy
Seventh Degree Black Belt

Please log in to comment
0
Thanks "GillySpy."

If you have any more details about what needs modified on our mail server I would appreciate it. e.g., which RFC #, section, etc.

Thanks,

djz
Answered 11/10/2011 by: zookdj
Second Degree Blue Belt

Please log in to comment
0
With this in mind: http://www.w3.org/Protocols/rfc1341/4_Content-Type.html many would expect to see an image have name parm, or a text file have a charset parm.
e.g
Content-Type: text/html; charset="us-ascii"
or
Content-Type: image/png; name="image001.png"

The enhancement is to pull it out of content-disposition filename if missing since that is more widely accepted and more well-defined.
http://www.ietf.org/rfc/rfc2183.txt
Answered 11/10/2011 by: GillySpy
Seventh Degree Black Belt

Please log in to comment
0
Thanks Gerald. I'll report it to our mail server vendor.

djz
Answered 11/18/2011 by: zookdj
Second Degree Blue Belt

Please log in to comment
0
Hi Gerald,

Got an update for you from Kerio tech support...

"Kerio does use the Content-type parameter for attachments and follows the correct RFC's for this. What mail client are you using to create these messages in and what type of attachments?

I would suggest that you check, using webmail to view the source of a sent message to this system, to verify that the correct content-type is show as it should be, again we would need to see the source if this is not correct."

When I looked at a message I sent to support@lehmans.com (which the KBox picks up), the file attachment in the message has this:

--=-aOCFw33qgu7wQdwaQ61q Content-Type: application/octet-stream Content-Disposition: attachment; filename="ENU-DistributionAgreement.pdf" X-MAPI: QkFTRTY0OiIvdGFncy8wZTIwMDAwMyIgIkxPTkcgMDAwMzQ4MDUiICIvdGFncy8zNzBi MDAwMyIgIkxPTkcgZmZmZmZmZmYiICIvdGFncy8zNzEwMDAwMyIgIkxPTkcgMDAwMDAwMDAi Content-Transfer-Encoding: base64


Looks like the "filename" parameter is there. Is that different than the "name" parameter?

Anyway, looks like I'll have to wait until KACE makes the planned change on their end since Kerio thinks they are doing things per the RFC and are not likely to make changes just because the KBox doesn't follow them.

djz
Answered 11/23/2011 by: zookdj
Second Degree Blue Belt

Please log in to comment
0
yes filename is a different parm. We have made the change so if you need this please let us know (with a ticket) or it will hopefully be in 5.4

One could definitely argue that Kerio is following the minimum standard. Many vendors implement the full RFC and then some apparently. I can only go by customer experience so there is a lot of conjecture here by me. I don't keep up to date on all the different mail apps out there.
Answered 11/23/2011 by: GillySpy
Seventh Degree Black Belt

Please log in to comment
Answer this question or Comment on this question for clarity