[rt-users] RT 3.6.6 Silently Dropping Messages with Attachments

[Michael Maxwell]

Thank you Michael for your help.  I checked /etc/my.cnf and we have already
given the following values under the [mysqld_safe] section:

key_buffer=16M
key_buffer_size=32M
max_allowed_packet=16M
thread_stack=128K
thread_cache_size=64
query_cache_limit=8M
query_cache_size=64M
query_cache_type=1
join_buffer_size=512K
max_connections=150
log_slow_queries=/var/log/mysql-slow.log

Unfortunately, this doesn't seem to have solved the problem.



On 6/25/08 6:30 PM, "Michael Brader" <michael.brader at youramigo.com> wrote:

> Michael Maxwell writes:
>> Hello,
> 
> Hi Michael
> 
>> Forgive me if this has been answered elsewhere, but if so, I must
>> have missed it.
> 
> I found the answer in http://wiki.bestpractical.com/view/FAQ but only
> because I already knew the answer. Searching for 'dropped attachments'
> or 'attachments silently dropped' returned nothing.
> 
> However, searching for 'site:wiki.bestpractical.com attachments
> silently dropped' in Google brings it up no problem.
> 
>> We have rt-3.6.6 running on linux (CentOS 4.6).  We're using fetchmail as
>> the means of getting email to the system from an IMAP server hosted offsite.
>> Normal emails (emails without attachments) go through fine and create
>> tickets as expected.  However, any message that contains an attachment of
>> any size never seems to make it through to RT.  [...]
>> 
>> Set($TruncateLongAttachments , undef);
>> Set($MaxAttachmentSize , 10000000);
>> Set($DropLongAttachments , undef);
>> 
>> Any help or pointers to things to check would be greatly appreciated.
> 
> Check your database for the largest transaction it can handle. In
> MySQL that's the max_allowed_packet. You can check it by running 'show
> variables'
> 
> | max_allowed_packet              | 8387584 |
> 
> Any attachment greater than that size will be dropped. I think the
> default value is 1MB. When that happens, we get a stacktrace in the RT
> log. We're quite happy to not allow attachments that size in, so we
> monitor the logs and when it happens we grab the file from our
> procmail holding area if it's useful or re-educate the requestor
> otherwise.
> 
> Hope this helps,
> Michael