Hello,
We recently had a phishing message make it through our spam filters and arrive at a mailing list. The good news is that since it was not from a list member it was in the held message queue.
I was able to find the message in the var/messages directory by searching for a keyword in the subject. However, after rejecting the message from Postorius, the message doesn't seem to be removed from the var/messages directory.
Is this expected behavior? I know that infosec people won't be too happy about a phishing email sitting around on our disk. (Infosec guys are notoriously paranoid. :) )
Is there some sort of cleanup process that would remove these messages? If not, does this pose an issue where over time disk usage will creep up? This could be a pretty significant problem if that is the case.
What do you think, sirs?
-Darren
On 04/26/2018 08:43 AM, Darren Smith wrote:
We recently had a phishing message make it through our spam filters and arrive at a mailing list. The good news is that since it was not from a list member it was in the held message queue.
I was able to find the message in the var/messages directory by searching for a keyword in the subject. However, after rejecting the message from Postorius, the message doesn't seem to be removed from the var/messages directory.
Do you mean Reject and not Discard? Phishing/Spam should never be "rejected" for backscatter reasons. Reject should only be used for somehow inappropriate posts from known people.
Is this expected behavior? I know that infosec people won't be too happy about a phishing email sitting around on our disk. (Infosec guys are notoriously paranoid. :) )
Is there some sort of cleanup process that would remove these messages? If not, does this pose an issue where over time disk usage will creep up? This could be a pretty significant problem if that is the case.
It's not the behavior I would "expect", but it is the way it currently works, and yes, all your concerns are valid. This is <https://gitlab.com/mailman/mailman/issues/257> which I just edited to note that in addition to not removing the pending db entry, the message isn't removed either.
-- Mark Sapiro <mark@msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan
Mark,
You're quite right, I meant Discard.
Thanks for the clarification. I hope to be able to pull a fix in for this in the near future. :)
-Darren
On Thu, Apr 26, 2018 at 10:14 AM, Mark Sapiro <mark@msapiro.net> wrote:
On 04/26/2018 08:43 AM, Darren Smith wrote:
We recently had a phishing message make it through our spam filters and arrive at a mailing list. The good news is that since it was not from a list member it was in the held message queue.
I was able to find the message in the var/messages directory by searching for a keyword in the subject. However, after rejecting the message from Postorius, the message doesn't seem to be removed from the var/messages directory.
Do you mean Reject and not Discard? Phishing/Spam should never be "rejected" for backscatter reasons. Reject should only be used for somehow inappropriate posts from known people.
Is this expected behavior? I know that infosec people won't be too happy about a phishing email sitting around on our disk. (Infosec guys are notoriously paranoid. :) )
Is there some sort of cleanup process that would remove these messages? If not, does this pose an issue where over time disk usage will creep up? This could be a pretty significant problem if that is the case.
It's not the behavior I would "expect", but it is the way it currently works, and yes, all your concerns are valid. This is <https://gitlab.com/mailman/mailman/issues/257> which I just edited to note that in addition to not removing the pending db entry, the message isn't removed either.
-- Mark Sapiro <mark@msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan
Mailman-users mailing list mailman-users@mailman3.org https://lists.mailman3.org/mailman3/lists/mailman-users.mailman3.org/
participants (2)
-
Darren Smith -
Mark Sapiro