I would like to store e-mails sent by me to others using the "From" field to a folder called "/sent"
So, I use:
:0:
*^From.*user#outlook.com
$HOME/Mail/sent/.
And it used to work fine. However, now I am also forwarding my e-mail from the address:user#outlook.com, what is happending is that the e-mail envelope contains the header: Resent-From.*user#outlook.com so all forwarded e-mail is being saved to the sent folder.
Is it possible to have a double condition. That is something that says that if both Resent-From and From have *user#outlook.com, then it should go to the sent-folder. In other words, is it possible to use a AND or OR or Negation condition.
Update: The provided solution is correct. I was making an error in that I had neglected the ":". Thanks for both the solution and the patience. I also learnt a number of things and about a number of resources, for which also I am grateful,
Thanks!
Procmail by default does exactly what you ask. Multiple conditions will be ANDed together. The first one which fails causes the recipe to be abandoned; if they all succeed, the action is taken.
:0 # second colon removed - don't use lock on directories
* ^From:(.*\<)?user#outlook\.com
* ^Resent-From:(.*\<)?user#outlook\.com
$HOME/Mail/sent/.
Notice also how I modified your regex to tighten it up.
To do NOT, add a ! in front of the condition. To do OR, you can negate both conditions, and take the action in the "else" part (de Morgan's law).
:0
* ! First condition
* ! Other condition
{ } # do nothing
:0E # else, meaning at least one was true
action
Of course, if both conditions are regular expressions, you can simply use the regex or operator.
:0
* First condition|Other condition
action
Related
I'm trying to use procmail to tidy up some old email into my thunderbird mbox file, however I can't seem to get it to file into an mbox file when using braces. Doing the simple test below with and without braces provides different outcomes - what am I missing, please:
SHELL=/bin/sh
# --- OPTIONAL, USED FOR DEBUGGING (comment out)
VERBOSE=yes
LOGABSTRACT=all
LOGFILE="procmail.log"
MAILDIR=/home/jake/windows/Thunderbird/Mail/Local\ Folders
DEFAULT=/home/jake/done/
# goes into MAILDIR/processed
:0
processed
# goes into DEFAULT/msg.gAmAAAAA4F/etc.
:0
{
processed
}
Your second recipe is basically a syntax error, though the Procmal parser actually parses it into an expression which however means something totally different than you intended. Here's what you have actually written, spelled out in full.
:0
{
processed=''
}
So Procmail enters the braces, performs the assignment, exits the braces, and delivers to $DEFAULT when it falls through to the end of the recipe file.
To actually deliver into a file, you need a full recipe like
:0
{
:0
processed
}
... but obviously the outer recipe with the braces is completely redundant here.
The fact that a symbol on its own gets parsed as an empty variable assignment which clears the variable named by that symbol is unobvious and wildly confusing not only to beginners, so don't feel particularly bad that you couldn't figure this one out.
With VERBOSE=yes you should actually find that the log file shows you exactly this chain of events. Your log file will end up in your MAILDIR so perhaps you didn't find it...?
I've been searching and I can't seem to find even just a simple grep code to do what I want. I want to take a url such as r2---sn-vgqs7nes.googlevideo.com, but not r3---sn-2xouxaxq5u5-5cxs.googlevideo.com and put them into a seperate file. Everything between r2---sn- and .googlevideo.com changes. A few examples of the varients:
r2---sn-vgqs7nes.googlevideo.com
r4---sn-ab5l6n67.googlevideo.com
r4---sn-5hnednes.googlevideo.com
r12---sn-ab5l6nsz.googlevideo.com
r6---sn-a5mlrn7d.googlevideo.com
r3---sn-vgqsrn76.googlevideo.com
r6---sn-p5qlsne7.googlevideo.com
r2---sn-qxo7snel.googlevideo.com
r4---sn-q4f7sn7z.googlevideo.com
r1---sn-o097znez.googlevideo.com
r6---sn-q4f7sn7e.googlevideo.com
The characters between sn-(randomizes).googlevideo.com
Also, r(number) goes up to r20. Basically, I want to extract them from a log file which constanty updates and input into one that doesn't so, I can later use them. From lets say /opt/var/log/messages to /opt/var/log/list. Another thing I'd like to also do is check to make sure the url doesn't already exist before it inputs it. Thanks in advance for any help.
#john-goofy The urls go from r1 to r20 for each variant. The urls such as these r3---sn-(2xouxaxq5u5-5cxs).googlevideo.com don't need to be collected. These variants of urls in parentheses is important not to be collected because blocking those blocks the videos entirely. Those also go from r1-r20, but the part in parentheses doesn't change besides this part in parentheses, but only one letter sn-2xouxaxq5u5-(5cxs).googlevideo.com. Which So, my desired output would be this:
Not collected:
- (r1-20) ---sn-2xouxaxq5u5-5cxs.googlevideo.com
- (r1-20) ---sn-2xouxaxq5u5-5cxe.googlevideo.com
- (r1-20) ---sn-2xouxaxq5u5-5cx?.googlevideo.com
- The third one I forget the letter.
- manifest.googlevideo.com
Collected:
Everything else such as the ones in my OP. I already have a few thousand collected, but it takes way too long manually doing each one.
(Blocking all these gets rid of youtube ads for the most part. There's some I think included in the above urls, but blocking them blocks everything.)
And it would all be inputted from /opt/var/log/messages to /opt/var/log/list
newbie asking first question :)
I'm running a mail server (Ubuntu/Postfix/Dovecot) with SpamAssassin. Most of the known spam is flagged (RBLs, and obvious UCE) except for this particular malspam in attached zip files like "order_info_654321.zip", "paymet_document_123456.zip", and so on, when it doesn't fit any other SA rules. I'd like to procure a rule which drops the matching offenders into oblivion.
After fiddling with regex101.com, I've come up with an expression that matches these patterns exclusively:
/\w+[_][0-9]{6}.zip$/img
Question is... How to format it all, get it to work, and where to put it? So far, I edited /etc/spamassassin/local.cf, added this to the bottom, and restarted:
mimeheader TROJAN_ATTACHED Content-Type =~ /\w+[_][0-9]{6}.zip$/img
describe ZIP_ATTACHED email contains a zip trojan attachment
score TROJAN_ATTACHED 99.
But it doesn't seem to do the magic. Where else can I look for this?
Thank you all,
Keijo.-
You have a wrong regex. You do not need a $ char at the end, because filename strings are not necessarily at the end of the Content-Type header. Instead, you can use a word boundary \b anchor. In my rules, I have the following, and it perfectly works:
mimeheader MIME_FAIL Content-Type =~ /\.(ade|adp|bat|chm|cmd|com|cpl|exe|hta|ins|isp|jse|lib|lnk|mde|msc|msp|mst|pif|scr|sct|shb|sys|vb|vbe|vbs|vxd|wsc|wsf|wsh|reg)\b/i
describe MIME_FAIL Blacklisted file extension detected
score MIME_FAIL 5
First up, SA doesn't drop e-mails by default, but it can score them so high on spam content that they don't show up to anyone's inbox. Second, the "ingredients" I started with were incorrect, plus messed up with SA ability to function at all.
This actually did the trick when added into/etc/spamassassin/local.cf:
full TROJAN_ZIPUNDS /\w*[_][\d]{1,6}\.zip/img
score TROJAN_ZIPUNDS 99
describe TROJAN_ZIPUNDS RM zip attached trojan underscore
Even though these spammers altered from zip to rar, to underscores to dashes, different filenames, and so on, creating rules to counter them became simple after succeeding with the first one. Here's what I added too:
full TROJAN_RARDASH /\w*[-][\d]{1,6}\.rar/img
score TROJAN_RARDASH 99
describe TROJAN_RARDASH RM rar attached trojan dash
Also, as first described, I needed to specifically block certain zip file names which soon morphed to rar and dashes, so, morphing the regex and appending as a rule triad to spamassassin's local.cf (and restarting) is currently holding, until next spam wave :-)
Finally, this is a very very blunt workaround, so anyone with expertise on the subject is more than welcome to chime in.
You are using the wrong mime header to check for the filename. Use this instead:
mimeheader TROJAN_ATTACHED Content-Disposition =~ /\w+[_][0-9]{6}.zip/img
Also make sure you have the MimeHeader plugin loaded.
loadplugin Mail::SpamAssassin::Plugin::MIMEHeader
I'm trying to create a regular expression in sieve. The implementation of sieve that I'm using is Dovecot Pigeonhole
I'm subscribed to github project updates and I receive emails from github with the subject in the format that looks like this:
Re: [Opserver] Create issues on Jira from Exception details page (#77)
There is a project name in square bracket included in the subject line. Here is the relevant part of my sieve script:
if address "From" "notifications#github.com" {
if header :regex "subject" "\\[(.*)\\]" {
set :lower :upperfirst "repository" "${1}";
fileinto :create "Subscribtions.GitHub.${repository}"; stop;
} else {
fileinto :create "Subscribtions.GitHub"; stop;
}
}
As you can see from the above, I'm moving the messages to appropriate project IMAP folders. So the message with the subject above will end up in Subscribtions.Github.Opserver
Unfortunately, there is one small problem with this script. If someone adds square brackets in the title of their github issue, the filter breaks. For example if the subject is:
[Project] [Please look at it] - very weird issue
The above filter will move the message to folder Subscribtions.Github.Project] [please look at it which is completely undesirable. I'd like it to be moved to Subscribtions.Github.Project anyway.
This happens because by default regular expressions are greedy. So they match the longest possible match. However when I try to fix it the usual way changing "\\[(.*)\\]" to "\\[(.*?)\\]" nothing seems to change.
How do I write this regular expression so that it acts as desired?
The answer is to change "\\[(.*)\\]" to "\\[([^]]*)\\]".
By reading regex spec linked in the question we disvover that POSIX regular expression are used. Unfortunately those do not support non-greedy matches.
However there is a work around in this particular case, given above.
as the linux kernel mailing list is really noisy, I want to discard all mails which are send to my mailbox from the LKML, but which are not from me, to me or as answer to one of my mails. I do already do some filtering and redirect all patch-mails (including [PATCH at the beginning of the subject) to another inbox as the "normal" LKML mails. But it is still much too much.
How to do this with procmail?
What I have atm:
:0
* ^Sender:\ linux-kernel-owner#vger\.kernel\.org
* (PATCH|patch)
$MAILDIR/ml.kernel_org.linux-kernel.patches/
The real challenge here is to articulate how to reliably identify messages which are replies to something you wrote. Are you satisfied with excluding messages which are To: or Cc: yourself?
:0
* ^Sender: linux-kernel-owner#vger\.kernel\.org\>
* ! ^From: Your Self <you#example\.net>
* ! ^TO_you#example\.net\>
/dev/null
(obviously, edit the addresses to match what your mail client really puts there).
Or perhaps you have a vanity domain, in which case (properly constructed) replies will have an easily identifiable Message-Id of yours at the start of References:?
:0
* ^Sender: linux-kernel-owner#vger\.kernel\.org\>
* ! ^From: Your Self <you#example\.net>
* ! ^TO_you#example\.net\>
* ! ^References:[ ]*<[^<>#]*#yourdomain\.example\.net>
/dev/null
(the whitespace inside the square brackets should be a tab and a space).
Or you could expand that a bit to look for your domain anywhere in References:, to also include replies to replies to yourself, if you want that.
Or you could keep a local copy of all your outgoing message-id:s and look for them in References:, but that is already a significant endeavor which I will only point out as a possibility if you cannot use any of the above. (I do believe it has been hashed out in more detail before, perhaps on the Procmail mailing list.)
As an aside, I would change the "patch" rule to only examine the Subject: line. A match on "patch" in any other header is extremely likely to be a false positive. If you want to examine the body, you need extra flags, perhaps like this:
:0
* ^Sender: linux-kernel-owner#vger\.kernel\.org\>
{
:0
* ! B ?? \<patch\>
* ! ^Subject:(.*\<)?patch\>
{ } # empty "then", just so we can continue to "else"
:0E
$MAILDIR/ml.kernel_org.linux-kernel.patches/
# While we are inside these braces, let's continue with other LKML stuff
:0
* ! ^From: Your Self <you#example\.net>
* ! ^TO_you#example\.net
/dev/null
# Any additional LKML recipes? Add them here
# Anything which falls through here is regular LKML
:0
$MAILDIR/ml.kernel_org.linux-kernel/
}
(This can obviously be refactored in a number of different ways. Remember De Morgan's laws: NOT (A OR B)<=> NOT A AND NOT B.)
As a safety measure, you might want to look for messages which actually carry a patch as an attachment, rather than filter the discussion about such messages? That can also become quite complex, because there is a number of different ways to represent a patch as a MIME attachment (and some are also sent completely in-line, in a regular text/plain part amongst other text) but that isn't insurmountable, either, just significant drudgery.