KACE Product Support

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.

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?

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

@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

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.

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.

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

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

Thanks Gerald. I'll report it to our mail server vendor.

djz

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

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.