Limited email blacklisting by subject and address alone

General discussions and other topics.
18 posts Page 2 of 2
by forumvisitor » Thu Mar 17, 2022 3:31 pm
Hi

I agree that the permissions for .procmailrc are more likely to be 600, since I don't think that file is executed by anything. And for now, I want to avoid creating extra log files to maintain, unless I get stuck of course.

So, I this strategy that should allow me to easily see what's happening. I added the following test configuration to my ~/.procmailrc file with permissions 600:

Code: Select all

:0 c
* ^Subject.*mytest
| formail -a "X-MYTEST test email"
I then sent myself two test email messages. The first had the subject "test" and the second "This is mytest". Both emails were received, but the "X-MYTEST" header did not appear in the second message, so I assume the filter did not fire. These possibilities occurred to me:

1. Typo in my filter
2. Some command required to notify that .procmailrc was just created or updated?
3. Sonic takes some specified time to notice and read changes to .procmailrc?

Or something else. And note that at the end of the day I will be just be replacing the filter line to detect headers/values in which I'm interested, and the action line will be to cause the email end up in my current graymail folder as set up by Sonic. So, I might as well ask now, what is the name of that folder i.e. will the action line just the word graymail or some other variable which tells Sonic to do that?

Thanks.

Joe
by apl » Thu Mar 17, 2022 4:09 pm
Did you set the spool file with
MAILDIR = /var/spool/mail/[your path as I described it earlier]

This is also why I suggested turning on logging with
LOGFILE = $HOME/.procmaillog
That's a good way of resolving questions like whether there is something wrong with the rule, or it is just not executing at all.
by forumvisitor » Fri Mar 18, 2022 12:00 pm
Hi

I should have mentioned this before, but I assumed that perhaps your shell account was different. The /home2/XX/YY/USERNAME does exist. But in /var/spool/mail/, there are no numbered directories or files...and my username is not there either? You said the spool should be there. Did you mean it is created only after I update .procmailrc with one of the following and presumably wait for a while?

Code: Select all

MAILDIR=/var/spool/mail/XX/YY/username
MAILDIR=/var/spool/mail/username
In the meantime, since you have not mentioned any typos etc, then I must resort to the logging approach anyway. There is no harm in temporarily adding "LOGFILE = $HOME/.procmaillog", since I can easily remove it. I'll repeat my tests with that.

In the mean time, this is an include file so I assume its changes will be propagated downstream to Sonic processing after this rule. Since I don't really want any of my regular mail to be logged anywhere other than where Sonic does it now, is there a way to log just this test rule? i.e. following my preference to not interfere with any of Sonic's normal filtering and logging?

Thanks.
by forumvisitor » Fri Mar 18, 2022 12:12 pm
Hi

Your suggestion for the following worked first time:

Code: Select all

LOGFILE=$HOME/.procmaillog
I got logging and now it's just a matter of working with that information. There is no need to reply to the message just before this one.

Thanks.
by forumvisitor » Fri Mar 18, 2022 2:17 pm
Hi

With your help, it has all worked out nicely. I got to the stage I wanted (almost). I will summarize here for future readers. I added the following to my $HOME/.procmailrc file as advised:

Code: Select all

LOGFILE=$HOME/.procmaillog
:0fw 
* ^Subject.*mytest
| formail -a "X-MYTEST: test email"
My test email was successfully delivered and must have triggered the above rule, because it does contain the appended header "X-MYTEST" and value. I do not intend to change headers in general, but it provided an easy to check external effect. For future reference, the internet does mention that using a trailing colon "0fw:" (i.e. locking) may be required under some circumstances.

Now all that remains is to send that mail to Sonic's graymail folder, not a local folder in my shell account that I would have to log into and check. I tried the obvious guess:

Code: Select all

:0
* ^Subject.*mytest
graymail
The test email was not delivered, so it went somewhere. Logging shows no issues, but I do not see it in Sonic's graymail via the webtools interface. So, one question remains: Is there an env variable e.g. $GRAYMAIL which holds the name I need to tie back into Sonic's email handling downstream?

Thanks.
by apl » Fri Mar 18, 2022 4:00 pm
You want
.Graymail/

See
viewtopic.php?f=13&t=5350&start=192
by forumvisitor » Sat Mar 19, 2022 12:25 pm
Hi

Using the suggested ".Graymail/" as a procmail folder seemed like it should work, but it only created a local folder of that name containing the matched email. I could not see that email in either the webtools Graymail (Trapped Spam) page or the Graymail folder in the Sonic webmail client. In other words it appears to be a different folder from the email that gets trapped in those locations. That means the automatic clean up provided by Sonic after a specified number of days or number of messages will not delete these emails. I looked at the suggested topic, but did not see anything that would explain why this didn't work.

I also noticed that when I used "graymail" as the procmail folder in a previous post, the email was filtered to a local file of that name too, but I was looking at Sonic interfaces at the time. Today, I tried just "Graymail"...same result.

1. Unless I missed something, I still need to know the folder name to place on the procmail action line which will result in the email being directed to the official Sonic graymail folder assigned to my account i.e. the one which can be viewed by webtools or the webmail client and is cleaned up periodically.

2. Is it safe for me to simply delete the following, which were created during these posts in my shell account home directory: "graymail", ".Graymail" and "Graymail".

Thanks.
by forumvisitor » Mon Mar 21, 2022 11:44 am
Hi

I had to ask Sonic support for the folder name since I figured it could be anything they wanted it to be. The previous suggestion was very close. Below is how my procmail test looks now and it works. The last line is the path to the graymail folder so that the email shows up in Sonic's portal:

Code: Select all

:0
* ^Subject.*mytest
${DEFAULT}.Graymail/
So, now it's just a matter of setting the conditions when the email headers subject and address are not enough.

Thanks for all the help.
18 posts Page 2 of 2

Who is online

In total there are 33 users online :: 0 registered, 0 hidden and 33 guests (based on users active over the past 5 minutes)
Most users ever online was 999 on Mon May 10, 2021 1:02 am

Users browsing this forum: No registered users and 33 guests