Mailing List Archive: questions regarding limit attachment size

questions regarding limit attachment size

May 12, 2015, 5:49 AM

Post #1 of 6 (2034 views)

Hi,

I have some questions regarding the functions to limit the attachment
size ($MaxAttachmentSize and $DropLongAttachments set):

1. Is it really necessary to log the first 60 characters of a dropped
attachment [1]?

2. As RT creates a attachment drop transaction (since RT 4.2.7), is it
still necessary to create a text attachment with the Content "Large
attachment dropped" for dropped attachments [2]?
The informations the text attachments make available are also available
by the "attachment drop" transaction (date, user, filename, filesize)
and thus are redundant (just to note that the transaction also shows the
$MaxAttachmentSize).

3. Wouldn't it be better to check an uploaded attachment on
Ticket/Create.html and Ticket/Update.html against the $MaxAttachmentSize
and give the user an error message (which gives the user a chance to
attach a smaller attachment) and abort the ticket create/update instead
of creating or updating the ticket with a "attachment drop" transaction

4. Maybe Ticket/Elements/AddAttachments should show a hint on the
$MaxAttachmentSize (if set) to prevent users from try to upload
attachments which are greater than $MaxAttachmentSize.

Chris

[1] https://github.com/bestpractical/rt/blob/stable/lib/RT/Record.pm#L832
[2] https://github.com/bestpractical/rt/blob/stable/lib/RT/Record.pm#L841

Re: questions regarding limit attachment size [ In reply to ]

shawn at bestpractical

May 12, 2015, 8:28 AM

Post #2 of 6 (2006 views)

Permalink

Hi Chris,

> 2015/05/12 8:49ã€Christian Loos <cloos@netcologne.de> ã®ãƒ¡ãƒ¼ãƒ«ï¼š
>
> Hi,
>
> I have some questions regarding the functions to limit the attachment
> size ($MaxAttachmentSize and $DropLongAttachments set):
>
> 1. Is it really necessary to log the first 60 characters of a dropped
> attachment [1]?

I think this is done to make dropped attachments easier to debug. One of the ways to triage any RT problem is to inspect the logs, and including a snippet of the email helps in identifying the problem.

> 2. As RT creates a attachment drop transaction (since RT 4.2.7), is it
> still necessary to create a text attachment with the Content "Large
> attachment dropped" for dropped attachments [2]?
> The informations the text attachments make available are also available
> by the "attachment drop" transaction (date, user, filename, filesize)
> and thus are redundant (just to note that the transaction also shows the
> $MaxAttachmentSize).

I donâ€™t have any insight into this one, but Iâ€™m open to getting rid of the old-style transaction if we can! Itâ€™s possible it was intentionally kept around to help preserve backwards compatibility with existing customizations.

> 3. Wouldn't it be better to check an uploaded attachment on
> Ticket/Create.html and Ticket/Update.html against the $MaxAttachmentSize
> and give the user an error message (which gives the user a chance to
> attach a smaller attachment) and abort the ticket create/update instead
> of creating or updating the ticket with a "attachment dropâ€ transaction

Totally agreed. That would be a great improvement. :)

> 4. Maybe Ticket/Elements/AddAttachments should show a hint on the
> $MaxAttachmentSize (if set) to prevent users from try to upload
> attachments which are greater than $MaxAttachmentSize.

Same!

> Chris
>
> [1] https://github.com/bestpractical/rt/blob/stable/lib/RT/Record.pm#L832
> [2] https://github.com/bestpractical/rt/blob/stable/lib/RT/Record.pm#L841

Thanks!
Shawn

Re: questions regarding limit attachment size [ In reply to ]

jesse at bestpractical

May 12, 2015, 8:53 AM

Post #3 of 6 (2003 views)

Permalink

> On May 12, 2015, at 8:28 AM, Shawn Moore <shawn@bestpractical.com> wrote:
>
>
>> 3. Wouldn't it be better to check an uploaded attachment on
>> Ticket/Create.html and Ticket/Update.html against the $MaxAttachmentSize
>> and give the user an error message (which gives the user a chance to
>> attach a smaller attachment) and abort the ticket create/update instead
>> of creating or updating the ticket with a "attachment droph transaction
>
> Totally agreed. That would be a great improvement. :)

Indeed it would, though there's still the case of asynchronous ticket creation (by mail, for example) to consider. The original design intent was that RT should try hard to lose as little data as possible, so we wanted to accept tickets submitted by users, even if we weren't capable of storing large attachments they sent.

The old behavior was never 'good', but was designed to try to make the best of bad situations.

Re: questions regarding limit attachment size [ In reply to ]

alex at chmrr

May 12, 2015, 9:16 AM

Post #4 of 6 (2006 views)

Permalink

On Tue, 12 May 2015 11:28:28 -0400 Shawn Moore
<shawn@bestpractical.com> wrote:
> > 2015/05/12 8:49ã€Christian Loos <cloos@netcologne.de> ã®ãƒ¡ãƒ¼ãƒ«ï¼š
> > 1. Is it really necessary to log the first 60 characters of a dropped
> > attachment [1]?
>
> I think this is done to make dropped attachments easier to debug. One
> of the ways to triage any RT problem is to inspect the logs, and
> including a snippet of the email helps in identifying the problem.

Is it necessary? No. Potentially useful? Yes.

> > 2. As RT creates a attachment drop transaction (since RT 4.2.7), is it
> > still necessary to create a text attachment with the Content "Large
> > attachment dropped" for dropped attachments [2]?
> > The informations the text attachments make available are also available
> > by the "attachment drop" transaction (date, user, filename, filesize)
> > and thus are redundant (just to note that the transaction also shows the
> > $MaxAttachmentSize).
>
> I donâ€™t have any insight into this one, but Iâ€™m open to getting rid of
> the old-style transaction if we can! Itâ€™s possible it was intentionally
> kept around to help preserve backwards compatibility with existing
> customizations.

In part backwards compatibility -- in part, to have a placeholder
attachment, for forwards and the like. It is not obviously more
correct to me to have the representation of the email have a _lack_ of
attachment, then to have an attachment whose role is to signal that
there _was_ an attachment.

- Alex

Re: questions regarding limit attachment size [ In reply to ]

elacour at easter-eggs

May 12, 2015, 10:04 AM

Post #5 of 6 (2005 views)

Permalink

Le 12/05/2015 17:53, Jesse Vincent a Ã©crit :
>
> Indeed it would, though there's still the case of asynchronous ticket creation (by mail, for example) to consider. The original design intent was that RT should try hard to lose as little data as possible, so we wanted to accept tickets submitted by users, even if we weren't capable of storing large attachments they sent.
>
>

but user can already get a bounce if it exceeds mta size limit. So why
RT shouldn't do the same?

I didn't use MaxAttachmentSize, except ensuring that it's ok with my
mta/db settings (this mta/rt relation would be nice to add in RT docs).

I think rt is missing a MaxMessageSize which will be a limit on the
total mail size. Maybe two options, one for incomming emails, one for
the web UI.

The most wanted is on the web UI side, RT should really limit the mail
size before sending it to the mta so a proper message could be printed
back on the web ui as soon as possible (rather than reccording the mta
error message in ticket history).

my 2 cents ;)

--
Easter-eggs SpÃ©cialiste GNU/Linux
44-46 rue de l'Ouest - 75014 Paris - France - MÃ©tro GaitÃ©
Phone: +33 (0) 1 43 35 00 37 - Fax: +33 (0) 1 43 35 00 76
mailto:elacour@easter-eggs.com - http://www.easter-eggs.com

Re: questions regarding limit attachment size [ In reply to ]

jesse at bestpractical

May 12, 2015, 1:40 PM

Post #6 of 6 (2005 views)

Permalink

> On May 12, 2015, at 10:04 AM, Emmanuel Lacour <elacour@easter-eggs.com> wrote:
>
> Le 12/05/2015 17:53, Jesse Vincent a Ã©crit :
>>
>> Indeed it would, though there's still the case of asynchronous ticket creation (by mail, for example) to consider. The original design intent was that RT should try hard to lose as little data as possible, so we wanted to accept tickets submitted by users, even if we weren't capable of storing large attachments they sent.
>
> but user can already get a bounce if it exceeds mta size limit. So why RT shouldn't do the same?

Different philosophy. When a user sends us email asking for help, I would rather be as friendly to them as possible. Ideally, RT should support both configurations.

Jesse