Prevent small social media icons from being imported into a ticket as a attachment

Help & Questions
1

Hi Travis,

Is it possible to set an image size limit to prevent social media icons from incoming emails from being imported as an attachment. We have set the parser to prevent duplicate attachments but this does not prevent the creation of the attachments entirely.

2

Hi @Tlek ,

It’s not currently possible to filter images by size.

Historically, we have been decidedly against this because it is a rudimentary way to filter images from a signature. We intended to release a much smarter method that tracks the number of times any particular image is received and suppresses that image once it’s obvious that it is included in a signature.

That said, we have yet to release the tracking feature I described, so let me look and see what we can do to release the ability to filter by size.

3

Hi Travis, I have to add to this post, We love Email2AT, but this is the one thing that we would accept/beg for almost ANY feature, even a rudimentary one, even a way we could simply blacklist a word in attachment name, anything to clean out attachments even if we have to write it ourselves. This is more than a nuisance. Anything you can do is appreciated.

4

Hi @bridaus . Thanks for weighing in!

I hear you.

Over the past few releases, we have been gradually adding logic that will enable the platform to recognize when an image is included in many different emails. The idea is that, over time, MSPintegrations will be able to identify the same image across many emails and threads and start to suppress that image intelligently.

This approach replaces checking image dimensions, which we believe is less reliable. Instead, the system learns the patterns of repeated images and blocks those that are clearly part of signatures.

In my opinion, it would be better if the system filtered attachments intelligently rather than requiring users to blacklist attachments based on name, dimensions, or other specific criteria.

I would be curious to hear your opinion on this. Do you agree that it would be better for the system to automatically learn and filter repeated images, or would you prefer having fine-grain control that requires you to manually filter based on file name, image size, or other metadata?

I’d appreciate your feedback as we consider the options.

Thanks!

5

Ok, you asked…, and without bounds this is what I’d recommend, I used to be an amateur developer and I’ve stayed at a Holiday Inn at some point…

  • Develop and expose the tools for fine grain control that also support generic operations on attachments.
  • Open those tools up to users for testing/use as soon as possible, let the early adopters test the tools that you are going to use under the hood when fully assembled to deliver your smarter system.
  • Those early adopters test, feedback on your architecture, and you can move onto the next pieces.
  • When done, you release the smart tool and everyone can test it while falling back on their custom solutions if it needs more work.
  • When fully realized, they turn off the old non-smart and use your new smart version.
  • If for some reason, the smart tool doesn’t work in one use case, users can write a tool of their own to address that case from the component tools.
  • The component tools/variables themselves have value that users will find other uses for…
  • This releases pressure on development, satisfies multiple needs, and I think is the best of both worlds.

I think the issue that needs addressing the most is the time that passes by while the perfect tool is being developed. Stated another way, I feel like if you exposed just a couple of variables, we could possibly write something immediately, it’s so close! (a testament to the already existing architecture).