3 ms·

I don't know. The final user should (somehow) create a .eml file of the suspect e-mail, then (in your current setup/workflow) send this .eml file as an attachm

by jaclaz 3y ago

I don't know. The final user should (somehow) create a .eml file of the suspect e-mail, then (in your current setup/workflow) send this .eml file as an attachment to the e-mail address of the service. I don't see the difference, once the .eml file is available, between sending it via e-mail as attachment and uploading it to a portal. On second thought, there is (in the second approach) another risk , the "original" suspect e-mail remains in the final user inbox, and in theory should be left alone until a verdict arrives, then the user should either delete the e-mail (if found to be a phishing attempt) or open it normally, but this is left to the care and diligence of the final user. It won't work, before or later the user will mis-read a notification from the system or couple it with the "wrong" e-mail. Imagine that the user receives 10 suspect e-mails, duly uploads (or sends) all of them to the service and waits diligently for the verdicts. The verdicts are 10 different e-mails from the service, 7 positives and 3 negatives, it would be easy to mismatch these notifications against the messages in the inbox, possibly interspersed with non-suspect ones.

emalderson 3y ago
Well, the user doesn't create any .eml, he just selects "forward as attachment" on the email, so the .eml file creation is transparent to him. For everything else, you're right. Unfortunately, the practice of leaving the responsibility to the user is too risky, but it's ok for a PoC. In a production environment, as we were saying in the previous comments, there should be a way to intercept the email before it reaches the user's inbox, make the analyst analyze it timely and then make the email arrive to the user's inbox afterwards. I don't think that's possible with a human-in-the-loop approach, but only in a fully automated scenario, which will never work as intended.
- jaclaz 3y ago
  >Well, the user doesn't create any .eml, he just selects "forward as attachment" on the email, so the .eml file creation is transparent to him. Hmmm, I believe it's not so given that an e-mail client (or web-mail interface) has such "forward as attachment" feature. Anyway, for the PoC anything goes, while for a possible future practical application this whole stuff must be automated and placed "before" the final user mailbox, I think we are fully agreeing on this.

by jaclaz 3y ago

emalderson 3y ago

Well, the user doesn't create any .eml, he just selects "forward as attachment" on the email, so the .eml file creation is transparent to him. For everything else, you're right. Unfortunately, the practice of leaving the responsibility to the user is too risky, but it's ok for a PoC. In a production environment, as we were saying in the previous comments, there should be a way to intercept the email before it reaches the user's inbox, make the analyst analyze it timely and then make the email arrive to the user's inbox afterwards. I don't think that's possible with a human-in-the-loop approach, but only in a fully automated scenario, which will never work as intended.

jaclaz 3y ago
>Well, the user doesn't create any .eml, he just selects "forward as attachment" on the email, so the .eml file creation is transparent to him. Hmmm, I believe it's not so given that an e-mail client (or web-mail interface) has such "forward as attachment" feature. Anyway, for the PoC anything goes, while for a possible future practical application this whole stuff must be automated and placed "before" the final user mailbox, I think we are fully agreeing on this.