I have some questions regarding the functions to limit the attachment
size ($MaxAttachmentSize and $DropLongAttachments set):
Is it really necessary to log the first 60 characters of a dropped
attachment [1]?
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).
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
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.
I have some questions regarding the functions to limit the attachment
size ($MaxAttachmentSize and $DropLongAttachments set):
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.
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.
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.
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.
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.
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.
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.
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.
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).
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.
