Limited email blacklisting by subject and address alone

General discussions and other topics.
18 posts Page 1 of 2
by forumvisitor » Sun Mar 13, 2022 3:47 pm
Hi

The email blacklisting facilities provided by Sonic webtools "enable" users to have some control of their incoming email. This "enabling" is a feature for which Sonic is well-known. However, I do not understand why we appear to be restricted to just "address" and "subject" out of all of the possible email headers?

Unless I've simply missed the right place to look, why aren't customers provided with a menu option "enabling" them to type in the email header of their choice rather than that chosen by Sonic, who can't possibly know which headers their customers are interested in blacklisting? That would of course allow the customer to type in "from" or "subject" as well as other headers. After that the entry is simply associated with a value field just like those currently used for the hard-coded ones?

And even if this hard-coding was to "keep it simple" for users, then why not leave the hard-coded two as they are now and add just one extra option to type in a custom header as users see it in their emails and then use its value in the filtering?
by keilanisonic » Mon Mar 14, 2022 10:49 am
Hello, You can adjust how many points certain words/etc. are worth to the spam assassin by going to Email (https://members.sonic.net/email/) > Spam filtering (https://members.sonic.net/email/spam/) > Modify Scores (https://members.sonic.net/email/spam/scores/) Unfortunately, we do not have a way to filter by headers yet. We appreciate your feedback, and I will pass along these suggestions.
Keilani H
Community & Escalations Specialist
Sonic
by kgc » Mon Mar 14, 2022 10:52 am
Try searching the forums for procmail.
Kelsey Cummings
System Architect, Sonic.net, Inc.
by forumvisitor » Mon Mar 14, 2022 11:53 am
Hi

Thanks for the replies so far. I think that blacklisting and spamassassin overlap in behavior but fulfill different functions. I suppose that is why Sonic provided the two features. In my case, I want to detect an email header and blacklist or stop that email right there...no further processing or weighting etc.

Sonic support have informed me that I cannot add new rules to spamassassin, although I do see a customize link for existing ones. If you know of a way to customize an existing rule to target an arbitrary email header which is not currently mentioned, please let me know because that would work. I could customize that rule and set a high enough weighting to bounce that email to the gray folder.

As for procmail, I will look into that next to see what options it offers.

Thanks.
by forumvisitor » Tue Mar 15, 2022 1:24 pm
Hi

I've now reviewed the "search forum for procmail" suggestion.

It looks (looked) promising. I still have (had) questions concerning how it interacted with whatever Sonic filtering does now. That's because Sonic's current filtering is not bad at all...or at least serves my needs to date, barring the one reason I opened this issue. I don't want to disrupt that filtering. I'm just looking for an additional filtering on top of what's currently available.

However, before investigating further, I checked for issues with procmail itself, and unfortunately came across this wikipedia reference (https://en.wikipedia.org/wiki/Procmail). Here's the main quote for convenience:
Procmail is stable, but no longer maintained, and a number of security vulnerabilities have been discovered since its last release.[3] Users are advised by procmail's last maintainer, Philip Guenther,[4] to use an alternative tool, because procmail is not suited for MIME traffic.
The numbered references above are associated with that article. As useful as the procmail angle looks, is it wise for me to build on it at this time? The mention of buffer overflows is particularly bothersome in any scenario, even though the above references have not provided actual proof...just suspicions. Those could make the Sonic server itself vulnerable, and I'd like to avoid being one of the few customers whose mailboxes are affected, just because I had to be different.

The article and its references do mention alternatives. However, although Sonic support apparently will assist with some procmail file configuration requests, do they assist or even support any of the alternatives?

Thanks
by kgc » Tue Mar 15, 2022 7:23 pm
All known vulnerabilities in our procmail have been patched.
Kelsey Cummings
System Architect, Sonic.net, Inc.
by forumvisitor » Wed Mar 16, 2022 2:56 pm
Hi

That's good news. I will follow the procmail trail, and hopefully find a way to add the extra filtering I need.

Thanks.
by forumvisitor » Wed Mar 16, 2022 5:08 pm
Hi

The procmail trail leads right back to the forum, as readers might have guessed. But at least I think I have the right questions to ask.

From a very old post in the forum, there is mention of a simple setup which would meet my requirements. In the below, the extra filtering would not cause harm if acting on multiple mailboxes, but it is only needed for one mailbox:

1. Sonic shell access seems a necessary first step and is not an issue.
2. Does anyone know if Sonic already looks for a procmail include file in a user's shell account? If so, what is the name and path of that file (e.g. ~/.procmailrc?)
3. What do the the permissions of the procmail include file need to be?
4. If the file exists and is empty, would the mailbox filtering behave as it does now i.e. standard Sonic filtering?

The idea of the above is that if I add this empty file first, no changes occur until I update the file with procmail filtering instructions. I can edit the file and add the instructions to detect and filter out specific header/value pairs of interest and then use emails to test the change until I get the result I want.

If Sonic is already looking for the file, then I need not make any further requests to support. Otherwise I assume the only way forward is for me to request that Sonic support make a change to their configuration to pick up the include file and provide me with the name and location the file?

Thanks
by apl » Thu Mar 17, 2022 10:09 am
2. Yes, I believe the config file will be detected automatically, and the filename is ~/.procmailrc
[These rules will run after sonic's spamassassin processing that is controlled by the web interface. If you need any rules to run before the spamassassin filtering you can put them in ~/.procmailrc-first
At least, that's the way it used to work. I think it still does, though I no longer have such a file.]

3. 700 works for me (probably should really be 600):
[apl@sh:~] ls -la .procmailrc
-rwx------. 1 apl user 311 Mar 20 2021 .procmailrc

4. Yes, an empty file should just act as a passthrough. But instead of an empty file you might need one with a few headers to point $MAILDIR to your mail spool directory and to turn on logging to $HOME/.procmaillog
[I should add that if your home directory on the shell server is /home2/XX/YY/USERNAME (where XX and YY are numbers, and USERNAME is your username) then your mail spool should be at /var/spool/mail/XX/YY/USERNAME
The mail spool directories themselves are not mounted on the shell server, though. The processing happens on a different machine.]
by forumvisitor » Thu Mar 17, 2022 11:47 am
Hi

Your instructions are very clear, so I will proceed along that path. If I run into any issues, I'll mention them here. When I'm sure it's working the way I intend, I'll also update this post with that result too.

Thanks
18 posts Page 1 of 2

Who is online

In total there are 26 users online :: 1 registered, 0 hidden and 25 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: Bing [Bot] and 25 guests