Attachments, Images and the Message That Is Too Big to Arrive

Wednesday, 11:05, at Ashgrove Housing. Fola in the housing team sends the desk three messages in forty minutes. The first has the subject "error" and the body "see attached". The attachment is a nine-megabyte photograph of her monitor, taken with her phone. It shows a dialog box at an angle with the ceiling lights reflected across the middle of it. The second, ten minutes later, has a screenshot pasted into the body. On the ticket it appears as a file called image001 and in the technician's list view as a blank square. The third, at 11:40, is a screen recording of the problem, thirty-eight megabytes, and it never arrives. Nobody at the desk knows it was sent. The only person who knows is Fola, and she believes it did.

An attachment is a file carried inside an e-mail alongside the text: a screenshot, a document, a log, a recording. An inline image is a picture placed in the body of the message rather than listed as a file. That is how a pasted screenshot usually travels. A size limit is the largest message a mail server or a ticketing tool will accept. There are at least three of them between a requester and a ticket, set by three different people, of which the smallest wins. The requester's message meets all three, in order, and the first one it fails is the one that decides whether anyone ever sees it. This article is part of our Email-to-Ticket Done Right series. It is about what the mail pipeline does with everything that is not text.

It covers the three places a size limit lives, with a table, and where attachments live once the ticket exists. Then come inline images and the logo problem, the screenshot that is the whole ticket, and the message that is too big to arrive. Next come sensitive content in attachments and attachments going out. It ends with a short war story and the attachment policy to copy, in that order.

The Three Places a Size Limit Lives

The first limit belongs to the sender's mail system, and it is applied before the message leaves. A requester attaching a file larger than their own server allows gets an error at the moment of sending, or a delivery failure a minute later. Either way they know. That is the good limit, because it fails loudly at the person who can do something about it. It is also the one the desk has least to do with, since it is set by whoever runs mail for the requester. That may be the same organisation or a customer's provider on another continent.

The second limit belongs to the mail server that holds the desk's mailbox. A message larger than it allows is refused. The refusal goes back to the sender as a delivery failure, which the sender may or may not read. The desk sees nothing, because the message never reached the mailbox. This is the limit the desk can find out and should write down, because it is the one most requesters will hit. The delivery failure it produces is a message most people file under "something from the mail system" without opening.

The third limit belongs to the ticketing tool, and it is the quiet one. The message arrived in the mailbox, and the tool read it. The tool has its own ceiling on what it will import, either for the message as a whole or for each attachment. What happens next depends on the tool. Some import the text and skip the attachment with a note on the ticket. Some import the text and skip the attachment with no note. Some leave the whole message in the mailbox and move on. Some mark it processed and create nothing. Only the first of those tells anybody. Find out which yours does with a message that is deliberately too big, as part of the tests in Testing the Mail Pipeline Before You Trust It. The documentation will say "attachments up to the configured limit are imported" and will not say what happens to the one that is not.

The number to tell requesters is the smallest of the three with a margin taken off. That is because a message's size on the wire is larger than the file inside it. Mail encodes attachments in a way that adds roughly a third to their size. So a file that is just under the limit on disk is over it in transit. A limit of twenty megabytes on the server means telling users fifteen and expecting a few to be surprised anyway. Write the number once, on the attachment policy, and put the policy where people find it when their message bounces. That is the knowledge base and the desk's acknowledgment, not an announcement nobody read in the spring.

Where Attachments Live Once the Ticket Exists

When the tool imports a message, the attachments are copied out of the mail and stored with the ticket. They are in the tool's database or in a folder on its disk, and from then on the ticket is where they live. What happens to the copy in the mailbox depends on what the tool does with processed mail. If messages are left in place or moved to a processed folder, there is a second copy there until someone empties it. If messages are deleted after import, the ticket's copy is the only one. Either way, the attachment store is part of the desk's data. It is backed up with the rest of it or it is not backed up at all. Ask where the store is and whether the backup includes it. The answer "it's in the database" is only an answer if the database is backed up with its files.

Capacity is the part nobody plans for, because the first year is small. A year of screenshots at a small desk is a modest folder. The first screen recording is thirty megabytes. The first phone video of a flickering screen is a hundred. The first requester who discovers that the desk accepts video sends four of them. If you run QuerySolv, everything the mailbox brings in lives on your own Windows server. In that case, the attachment store is your own disk and your own backup rather than a question for a provider. That is reassuring and also means the disk is yours to watch. In any tool, put the attachment store's free space on the same monitoring list as the mail server's quota. Decide now what happens to attachments on tickets closed years ago. Most desks never decide. The disk decides for them.

Inline Images and the Logo Problem

A pasted screenshot travels as an image file attached to the message and referenced from inside the body, so that a mail program shows it where it was pasted. A ticketing tool receiving that message has three choices, and tools make all three. It can show the image inline, as the sender saw it. It can strip it out of the body and list it as an ordinary attachment, usually with a name like image001. Or it can convert the body to plain text and lose the reference, so that the image is either an unexplained attachment or gone. Test it, with a pasted screenshot and with one attached as a file, and tell the desk what to expect. Where the tool lists pasted images as attachments, a technician's list view may show a blank square or a generic icon. In that case, the habit is simply to open it. The square is the ticket.

Signature logos are the same mechanism with less to say. Most organisations' mail signatures carry a small image, the logo, a social-media badge, a green "think before printing" leaf. Every message in a thread carries it again. A ticket with seven replies has fourteen copies of the requester's logo attached to it, each with a name like image002. Among them somewhere is the one screenshot that matters. Some tools filter very small images; some do not. The desk's own replies carry the desk's logo back, doubling the pile. Keep the desk's own signature as text, or with the smallest image the organisation will allow. Teach technicians to sort a ticket's attachments by size when looking for the real one. The logo is never the real one. It is only ever the most numerous.

The Screenshot That Is the Whole Ticket

"See attached" with a picture and a one-word subject is a complete ticket in the requester's mind, and it is not wrong. The picture contains the error text, the application, often the time on the clock in the corner and the name of the document that was open. What it lacks is any of that in a form the queue can search, sort or display. The ticket's title says "error". Its body says "see attached". A search for the error text next month will not find it. A colleague scanning the queue will not know what it is. A report by type will file it under nothing. Everything the desk needs is in the ticket and none of it is in the fields.

The triager's job is to move it from the picture into the fields, and it takes a minute. Open the image, read the error, and type it into the ticket. Put the exact message in quotes as the first line of an internal note. Include the application and the action that produced it, and the time if the clock is visible. Rewrite the title from "error" to "Housing system: 'record locked by another user' when saving tenancy". Now the ticket is searchable, scannable and reportable, and the next requester with the same error will match it. The general skill of turning a vague ticket into a specific one is in Translating the Vague Ticket. The attachment version is simply that the information is already there, in the wrong format.

A photograph of a screen is a screenshot's poorer cousin, and the desk should ask for the better one, once, kindly, with the how in the same sentence. "A screenshot would be clearer than a photo; on your keyboard the print-screen key copies the screen and you can paste it into the reply." Most people do not know the key, nobody has ever told them, and a sentence costs nothing. A photo, meanwhile, is read as best it can be. A phone photo at an angle with ceiling lights in it still usually shows the words that matter. A technician who replies "please send a proper screenshot" and waits has turned a one-minute ticket into a two-day one. Read the photo. Teach the key. Do both in the same reply.

The Message That Is Too Big to Arrive

The message that exceeds a limit fails in one of three ways, and only one of them tells the requester clearly. Refused at the sender's end, it produces an error on screen or a delivery failure within minutes, and most people act on it. Refused by the desk's mail server, it produces a delivery failure in the sender's inbox, from an address they do not recognise. The subject is one they have seen a hundred times on spam, and a fair number of people never open it. Accepted by the server but beyond the tool's limit, it produces nothing at all for the sender and, depending on the tool, nothing for the desk either. Fola's screen recording went the second way, and the delivery failure is in her inbox now, unread, between a newsletter and a meeting invitation.

The defence has two halves, and the desk owns both. The first is to tell people the limit and the alternative before they need it. Put the number, with its margin, on the attachment policy, and the alternative beside it. One alternative is to put the file on a shared drive and send the path. Another is to attach it through the web form if the desk has one and the form's limit is larger. Or, simplest of all, send the message without the file first and the file in a reply. That way, the ticket exists and has a number even if the file bounces. A ticket that exists can be chased. A message that bounced into an unread folder cannot.

The second half is the desk's own check for the quiet failure. Where the tool skips an oversize attachment with a note, the technician sees the note and asks for the file another way, and nothing is lost but a day. Where the tool skips it silently or leaves the message unread, the only evidence is in the mailbox itself. That could be a message in the inbox that has no ticket, or a message in the processed folder whose subject matches nothing in the queue. That check looks at the mailbox for messages the tool did not turn into tickets. It is part of the pipeline's regular testing rather than anyone's daily job. The desk should know which failure its tool produces before the first thirty-eight-megabyte recording arrives. It will arrive. People are proud of their screen recordings.

Sensitive Content in Attachments

A screenshot shows whatever was on the screen, and whatever was on the screen is now on a ticket that the whole desk can read. The password typed into a form and visible in the field; the spreadsheet of staff salaries open behind the error dialog; the patient record in the application the requester was using when it froze; the customer's full card number in the order screen. None of it was meant for the desk. All of it is now stored with the ticket, backed up with the ticket, and visible to every technician who opens the ticket. It is possibly visible to the requester's manager too, if the tool lets managers see their team's tickets. The requester did not think about this. Neither, usually, has the desk.

The policy is in two sentences, one for requesters and one for the desk. Requesters are asked, on the attachment policy and in the knowledge base, not to send passwords, personal data or customer data in screenshots, and to crop or cover anything that is not the error. The desk, on receiving something it should not have, writes an internal note saying what was received and that it was removed or restricted, removes the attachment where the tool allows it, and where the tool does not allow removal, restricts the ticket's visibility as far as the tool can and asks the requester to change any password that was visible. Tools differ on whether an attachment can be removed from a ticket once stored. Find out before the first time it matters, because that is a bad moment to be reading the documentation. What must never be written in a ticket in the first place, and what to do when it has been, is in What Not to Write in a Ticket. The rules there apply to pictures exactly as they apply to words.

Attachments Going Out

The desk's replies obey the same limits in the other direction. A technician who attaches an installer to a reply has sent a message that the requester's mail server will probably refuse. In that event, the delivery failure comes back to the desk's address. If the screening is not expecting it, the failure becomes a held message or a ticket of its own. Files that need to reach a requester go on a shared drive with the path in the reply. Or they go into the knowledge base if more than one person will ever need them. Or they go through whatever file-transfer arrangement the organisation has approved. The reply itself stays light: text, a link, a small image if the step genuinely needs one.

Two outgoing habits save trouble. First, do not attach a document that could have been a knowledge base article. The article can be updated, linked, and found by the next person. The attachment is a copy that was right on the day it was sent. Second, check what the reply carries before sending it, because some tools attach the ticket's existing files to every reply by default. In that case, the requester receives their own nine-megabyte photograph back, with the desk's logo, seven times. The requester will not complain. They will quietly conclude that the desk does not know how e-mail works, which is a harder reputation to lose than a slow one.

A Short War Story: The Field Tablet at Fairholme Surveyors

At Fairholme Surveyors, a site surveyor called Meera e-mailed the desk from a half-finished housing site about a field tablet. Its camera app crashed every time she tried to save a photo. She attached eleven of the photos it had managed to save, as evidence, forty-two megabytes in all. The firm's mail server refused the message and sent a delivery failure to the only address it had, which was the mailbox on the tablet. The delivery failure arrived under an unfamiliar sender name and was never opened. Meera, who had seen the message leave, assumed the desk had it. For nine working days she took her site photographs on her phone and transferred them by hand each evening. Then a second site visit had to be repeated because the photographs from the first were in the wrong format for the planning submission. That cost a day of her time, a day of the driver's, and an apology to the client. The desk, when she finally telephoned, had never heard of the ticket. It found the server's limit in a minute and wrote an attachment policy that afternoon. A message that bounces into an unread folder is indistinguishable, to everyone, from a message that was never sent.

The Attachment Policy

The policy below is one page, written for requesters and the desk together. It is meant to live in the knowledge base with a link from the acknowledgment. The numbers are blanks because they are yours: the smallest of your three limits with the margin taken off, the path to your shared drive, the name of your form. The second section, for the desk, is the part that keeps the first section honest. A policy that tells users to do something the desk has not tested will be found out by the first thirty-eight-megabyte recording. Fill in every blank before publishing it, and re-read it after any change to the mail server or the tool.

ATTACHMENTS AND THE HELP DESK — ONE PAGE
Desk address: ______________@example.com      Last checked: ________  by: ____________

FOR REQUESTERS
  What helps most
    A screenshot of the error, pasted into the message or attached as a file.
    The exact words of any error message, typed into the body as well.
    Log files or documents the problem relates to, if small.
  Size limit
    Keep the whole message under ______ MB. Larger messages are refused by the
    mail system and you will receive a delivery failure, not a ticket number.
  If your file is bigger than that
    1. Send the message first without the file, so you get a ticket number.
    2. Then do ONE of:
       [ ] Put the file on the shared drive at ______________________ and reply
           to the acknowledgment with the path.
       [ ] Attach it through the request form at ______________________, which
           accepts files up to ______ MB.
       [ ] Ask the desk; we will arrange another way.
  Screenshots, not photographs
    On most keyboards the key marked Print Screen (or PrtSc) copies the screen.
    Paste it into your message. A photo of the screen is fine if that is all you can do.
  Please do not send
    Passwords, even partly visible in a screenshot.
    Personal or customer data that is not part of the problem. Crop or cover it.
    Programs, scripts or archives, unless the desk has asked for them.

FOR THE DESK
  Limits (smallest wins)
    Our mail server accepts up to ______ MB.      Checked on ________
    The ticketing tool imports attachments up to ______ MB.   Checked on ________
    The request form accepts up to ______ MB.     Checked on ________
    Number given to requesters (smallest, less margin): ______ MB
  What our tool does with an oversize attachment (tested on ________)
    [ ] Skips it and adds a note to the ticket
    [ ] Skips it silently
    [ ] Leaves the message unread in the mailbox
    [ ] Marks the message processed with no ticket
    Check for messages without tickets: who ____________  how often ________
  Pasted images arrive as (tested on ________):  [ ] inline  [ ] attachment  [ ] lost
  Attachment store
    Location: ______________________   Free space checked by: ____________
    Included in backup: [ ] yes, confirmed on ________
  Sensitive content received
    1. Internal note: what was received, from whom, what was done.
    2. Remove the attachment if the tool allows; otherwise restrict the ticket.
    3. Ask the requester to change any password that was visible.
  Outgoing
    Files for requesters go on the shared drive or into the knowledge base; the
    reply carries the path or the link, not the file.
    Replies do not re-attach the ticket's existing files.

Fola's three messages became one ticket by lunchtime. The triager opened the photograph, read "record locked by another user", and typed it into the title and the note. The triager wrote back with a two-line fix and one sentence about the print-screen key. The screen recording was found four days later, when Fola mentioned it in passing and the technician asked her to look for a delivery failure. She found the failure, unread, where they always are. Nobody needed it by then. The next time she sent one, she put it on the shared drive and sent the path. The ticket had a number before the file had finished copying.

Frequently Asked Questions