This is a scenario I have at work.

We're receiving emails with .p7s attached files from a single user of a company(hence the company domain for eg. abc.com) our users interact with via mail. We use IBM Lotus Notes for our email.

There are other users of the same domain who also send our users emails but in those emails we do not see a p7s file.

Also since we use a attachment filtration policy on our email gateway, the gw quarantines the email because of the file extension. The attachment filtration policy specifically contains p7s, p7m, pif, scr file formats, which were put there by some previous fella before. Which just raises another question about whether we should block this filetype at the email gateway?

Also we asked the same user to send us a simple plain text email for testing to our gmail accounts and the .p7s file wasn't attached to this email.

I read up on smime.p7s usage, but cannot understand why is it that only that one particular user's incoming email shows this file while others do not.

Also I guess I can just whitelist the .p7s extension and the emails won't be quarantined by the gw, would that be a security risk of some sort?

  • You asked the sender to send a plain text, but did you ask him/her to dig up what (s)he sent that has the attachments?
    – user13695
    Jul 25, 2016 at 14:45
  • @JanDoggen I think you referring to the part where the user emailed our gmail account. He just sent an email with basic text and then he did the same to our company domain, and the p7s attachment was not seen on gmail but appears on our email client - lotus notes.
    – allwynmasc
    Jul 25, 2016 at 15:08
  • Can you test these? --> What happens when your user sends email using other email software? What happens if another user from that same company sends you mail using the same software as your 'problem user'? What software are they using anyway?
    – user13695
    Jul 25, 2016 at 15:21
  • @JanDoggen well we only use lotus notes and im afraid i cant do that test, but the issue isn't our client, it's that our email gw blocks this person's email because it violates the attachment extension policy and that the attachment is visible only from this one user from the other side. I will have to find out what client they use at their end though, will update the post then.
    – allwynmasc
    Jul 25, 2016 at 15:41

1 Answer 1


I would suggest changing the policy to not quarantine "bad" mails, instead, use the policy word "DISCARD". But for p7s I would suggest stripping the attachment out, as these are signatures. However, they can contain S/MIME encrypted mails causing viruses to leak through. Stripping the attachment out and letting the rest through is safe.

For p7m, pif, scr, its better to DISCARD the whole mail silently without notifying either sender or receivr, without quaratine.

  • can you explain this "However, they can contain S/MIME encrypted mails causing viruses to leak through" a bit more. When do they actually leak viruses? And we have a policy to basically quarantine everything so nothing important is ever just deleted without manual intervention. So stripping the p7s sig is totally safe, also why do you say discard the p7m etc. attachments?
    – allwynmasc
    Jul 25, 2016 at 15:47
  • @allwynmasc As they are encrypted, it means that a mail containing a malicious file, can leak through your perimeter detection, as only the end user has the private key to decrypt it. Note that many E-mail program has mimesniff functions, which means it might detect that the p7s file is actually a p7m file, and "correct" it internally. Stripping the sig is totally safe, either it was a signature and then nothing would happen, or it was a malicious encrypted file and then it got removed. Jul 26, 2016 at 0:00
  • In many cases, its the only attachments that is the problem, not the mail itself, and thus its a bad idea to quarantine mails because it contains a "inpermissible" attachment. Thats why its better to have 3 security levels: 1: Good attachments - let through. 2: Risky attachments, not neccessarly bad - strip the attachment and let the rest through. 3: Known bad attachments, like .scr (screensaver, never legitimate to send in mail at all), .p7m (encrypted mail, attempt to bypass filters etc), then you simply toss the mail in /dev/null without notifying anyone. Jul 26, 2016 at 0:04
  • The problem with quarantining "bad" attachments is that you cannot know if they are safe. Take a encrypted mail for example, you cannot know if the attachment contains a virus, you either have the choice of deleting it or releasing it through. So quarantining only wastes space and encourages unsafe decisions. You can, as I said, usually decide with automatic tools if the file is worth keeping, and thus pass it on, or just discard the attach (for example, deleting office files containing macros, or deleting .scr). And in some cases, you can know from the attachment that the mail is abusive. Jul 26, 2016 at 0:09
  • well it's going to be very hard to change overall policies because of "how things are done here". So right now we just never delete anything! We have never received any p7m attachment files yet. And as i mentioned we get these p7s files from just one guy from the other side while his colleagues can mail us just fine. Could this then be a misconfig with his email client or a worm acting out on his pc? I still dont have the info on what client they use, i'll update that asap, mostly its got be outlook is my guess.
    – allwynmasc
    Jul 26, 2016 at 5:56

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.