RT 3.6.6 Silently Dropping Messages with Attachments


#1

Hello,

Forgive me if this has been answered elsewhere, but if so, I must have
missed it.

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. Fetchmail configuration
doesn’t appear to be an issue - and as far as fetchmail is concerned
(according to the documentation), attachments are a non-issue.

I’ve added a few lines to the RT_SiteConfig.pm to try to get it working, but
so far, no good. I have the following as the only options that pertain to
mail handling:

Set($TruncateLongAttachments , undef);
Set($MaxAttachmentSize , 10000000);
Set($DropLongAttachments , undef);

Any help or pointers to things to check would be greatly appreciated.

Thanks


#2

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

Michael Brader michael.brader@youramigo.com


#3

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@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


#4

Actually, I should point out that RT appears to be ignoring messages with
any attachment at all - size isn’t an issue.On 6/26/08 10:36 AM, “Michael Maxwell” mmaxwell@blackarrow.tv wrote:

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@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


#5

It turns out this problem was caused by an older version of perl’s IO::File
module. Ran a cpan update, updated the module, tested, and all is well.

CPAN strikes again…

Thanks everyone for your help.On 6/26/08 10:39 AM, “Michael Maxwell” mmaxwell@blackarrow.tv wrote:

Actually, I should point out that RT appears to be ignoring messages with
any attachment at all - size isn’t an issue.

On 6/26/08 10:36 AM, “Michael Maxwell” mmaxwell@blackarrow.tv wrote:

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@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


http://lists.bestpractical.com/cgi-bin/mailman/listinfo/rt-users

Community help: http://wiki.bestpractical.com
Commercial support: sales@bestpractical.com

Discover RT’s hidden secrets with RT Essentials from O’Reilly Media.
Buy a copy at http://rtbook.bestpractical.com