# SMTP - extension based file extraction issue
**URL:** https://forum.suricata.io/t/smtp-extension-based-file-extraction-issue/2875
**Category:** Help
**Created:** [October 17, 2022, 11:49am UTC](https://forum.suricata.io/t/smtp-extension-based-file-extraction-issue/2875 "2022-10-17T11:49:52Z")
**Posts on this page:** 2
**Page:** 1
### Author:  [@jiivas](https://forum.suricata.io/u/jiivas)
#### Post date: [October 17, 2022, 11:49am UTC](https://forum.suricata.io/t/smtp-extension-based-file-extraction-issue/2875/1 "2022-10-17T11:49:52Z")
Hello team,
it looks like the extension based file extraction isn’t working properly when the attachment name field contains additional information like it’s size.
This seems to occur when sending an attachment with a webmailer like roundcube.
email attachment name: “Invoice\_0439.img; size=1245184”
suricata rule:
alert smtp $MTA\_SERVERS any → $EMAIL\_SERVERS any (msg:“HUNTING [SOC] SMTP File Transfer (.img)”; fileext:“img”; classtype:bad-unknown; sid:6910209; rev:1; metadata:affected\_product Any, attack\_target Client\_Endpoint, deployment Perimeter, signature\_severity Minor;)
I’m not sure if this is the expected behaviour or an issue.
It can be worked around using mime type based extraction rules.
Bests,
jiivas
---
### Author:  [@Andreas\_Herz](https://forum.suricata.io/u/Andreas_Herz)
#### Post date: [November 17, 2022, 10:03am UTC](https://forum.suricata.io/t/smtp-extension-based-file-extraction-issue/2875/2 "2022-11-17T10:03:15Z")
This could be counted as a bug. Can you provide a pcap for that, so we could reproduce it and ideally write a suricata-verify test for it?