The common ethicete about mailing lists is to answer to a human, and CC the mailing list, like this:
To: help-volounter#dev.full
Cc: some-program#mailing-list.com
Subject: Re: Describtion of the problem
Problem is that I get two copies of such email(it's expected). I would like to procmail one copy to mailing list mbox, and another to inbox mbox. Is it simple way to do it?
It's not entirely trivial, but there are some building blocks you may find useful.
You can detect whether you have already received a message by keeping a cache of seen message-id:s. This is a standard technique described in the procmailex man page in more detail. I would propose to use the same technique to decide where to file an incoming message; if it has not been seen before, deliver to your inbox; otherwise, file to the list's folder.
The locking becomes somewhat more complex because you need to obtain the lock file before entering the formail -D recipe. This can be done by using the LOCKFILE special variable.
# Is this message addressed both to yourself and to the list?
:0
* ^TO_you#example\.net\>
* ^TO_mailing-list#elsewhere\.example\.org\>
{
# Select regular inbox as default target for this message
dest=$DEFAULT
# Lock msgid.lock for exclusive access to msgid.cache
LOCKFILE=msgid.lock
# If message-id is already cached, override $dest
:0
* H ? formail -D 8192 msgid.cache
{ dest=listbox/ }
# Release lock
LOCKFILE=
# Deliver to $dest
:0
$dest
}
This is not 100% foolproof. If you get a Bcc:, for example, your own address will not be in the headers, and so ^TO_ yourself will not match.
Related
This is pretty straightforward. I tried creating a rule in the EAC for sent messages, but it's not working as intended. Basically I need to create a rule that checks if any recipients (To, CC or BCC) are from outside my org. If there are any, append a disclaimer to EVERYONE in the recipients (including inside the org).
Doing this via the EAC doesn't work in the sense that when I specify the rule "If the message... is sent to 'Outside the organization' " it finds ONLY recipients outside the org and appends the disclaimer to them. However, I also need to append it for users inside the org if this condition verifies. Unfortunately doing it like this only recipients from outside the org are receiving the appended disclaimer, but not company workers.
I've been working with PS quite a lot lately and New-TransportRule seems to be the way to go to do this, but reading through the documentation hasn't helped me a lot on how to structure said query to do exactly what I want or even how to only apply it to one person for testing purposes.
Any of you guys worked with this cmdlet before and could give me a quick hand?
Thanks!
It's been some time since I've managed Exchange, but judging from the documentation, I'd say you could probably take advantage of the AnyOfRecipientAddressMatchesPatterns predicate (emphasis added):
-AnyOfRecipientAddressMatchesPatterns
[...]
The AnyOfRecipientAddressMatchesPatterns parameter specifies a
condition that looks for text patterns in recipient email addresses by
using regular expressions. You can specify multiple text patterns by
using the following syntax: "Regular expression1","Regular
expression2",..."Regular expressionN".
A match for this condition applies the rule action to all recipients
of the message. For example, if the action is to reject the message,
the message is rejected for all recipients of the message, not just
for the specified recipients.
So let's start by constructing an appropriate pattern:
# Define internal recipient domains
$internalDomains = 'ress.tld','internal.ress.tld','ress-alias.tld'
# Escape as literal regex pattern
$internalDomains = $internalDomains |ForEach-Object { [regex]::Escape($_) }
# Embed in negative look-behind pattern
$nonInternalDomainPattern = "(?<!#(?:$($internalDomains -join '|')))"
The resulting regex pattern will match any email not having any of the three domains listed:
PS ~> $nonInternalDomainPattern
(?<!#(?:ress\.tld|internal\.ress\.tld|ress-alias\.tld))$
PS ~> 'ress#ress.tld' -match $nonInternalDomainPattern # doesn't match on internal recipients
False
PS ~> 'iisresetme#example.org' -match $nonInternalDomainPattern # but it matches any other address
True
Now you just need to include it in a transport rule:
New-TransportRule "Disclaimer on all external communications" -AnyOfRecipientAddressMatchesPatterns $nonInternalDomainPattern -ApplyHtmlDisclaimerText '<your>html goes here</your>'
I basically want to check the incoming 'From' in the email received and then either
Keep it and make it deliver to the intended mailbox if the email matches a Specified MySQL/PostgreSQL
Database User (eg. select email from users where exists ('from email address') )
If the 'From' address is blank or it is not found in the database, the email should be discarded
Any way I can achieve this before the e-mail is delivered to the intended mailbox?
I am using Procmail + Virtualmin + Webmin + PostgreSQL
PS: I want to apply this filter not to the wole server but to some specified mailboxes/users (i'm assuming 1 user = 1 mailbox here)
Procmail can easily run an external command in a condition and react to its exit status. How exactly to make your particular SQL client set its exit code will depend on which one you are using; perhaps its man page will reveal an option to make it exit with an error when a query produces an empty result set, for example? Or else write a shell wrapper to look for empty output.
A complication is that Procmail (or rather, the companion utility formail) can easily extract a string from e.g. the From: header; but you want to reduce this to just the email terminus. This is a common enough task that it's easy to find a canned solution - generate a reply and then extract the To: address (sic!) from that.
FROM=`formail -rtzxTo:`
:0
* FROM ?? ^(one#example\.com|two#site\.example\.net|third#example\.org)$
{
:0
* ? yoursql --no-headers --fail-if-empty-result \
--batch --query databasename \
--eval "select yada yada where address = '$FROM'"
{ }
:0E
/dev/null
}
The first condition examines the variable and succeeds if it contains one of the addresses (my original answer simply had the regex . which matches if the string contains at least one character, any character; I'm not convinced this is actually necessary or useful; there should be no way for From: to be empty). If it is true, Procmail enters the braces; if not, they will be skipped.
The first recipe inside the braces runs an external command and examines its exit code. I'm imagining your SQL client is called yoursql and that it has options to turn off human-friendly formatting (table headers etc) and for running a query directly from the command line on a specific database. We use double quotes so that the shell will interpolate the variable FROM before running this command (maybe there is a safer way to pass string variables which might contain SQL injection attempts with something like --variable from="$FROM" and then use that variable in the query? See below.)
If there is no option to directly set the exit code, but you can make sure standard output is completely empty in the case of no result, piping the command to grep -q . will produce the correct exit code. In a more complex case, maybe write a simple Awk script to identify an empty result set and set its exit status accordingly.
Scraping together information from
https://www.postgresql.org/docs/current/app-psql.html,
How do you use script variables in psql?,
Making an empty output from psql,
and from your question, I end up with the following attempt to implement this in psql; but as I don't have a Postgres instance to test with, or any information about your database schema, this is still approximate at best.
* ? psql --no-align --tuples-only --quiet \
--dbname=databasename --username=something --no-password \
--variable=from="$FROM" \
--command="select email from users where email = :'from'" \
| grep -q .
(We still can't use single quotes around the SQL query, to completely protect it from the shell, because Postgres insists on single quotes around :'from', and the shell offers no facility for embedding literal single quotes inside single quotes.)
The surrounding Procmail code should be reasonably self-explanatory, but here goes anyway. In the first recipe inside the braces, if the condition is true, the empty braces in its action line are a no-op; the E flag on the next recipe is a condition which is true only if any of the conditions on the previous recipe failed. This is a common idiom to avoid having to use a lot of negations; perhaps look up "de Morgan's law". The net result is that we discard the message by delivering it to /dev/null if either condition in the first recipe failed; and otherwise, we simply pass it through, and Procmail will eventually deliver it to its default destination.
The recipe was refactored in response to updates to your question; perhaps now it would make more sense to just negate the exit code from psql with a ! in front:
FROM=`formail -rtzxTo:`
:0
* FROM ?? ^(one#example\.com|two#site\.example\.net|third#example\.org)$
* ! ? psql --no-align --tuples-only --quiet \
--dbname=databasename --username=something --no-password \
--variable=from="$FROM" \
--command="select email from users where email = :'from'" \
| grep -q .
/dev/null
Tangentially, perhaps notice how Procmail's syntax exploits the fact that a leading ? or a doubled ?? are not valid in regular expressions. So the parser can unambiguously tell that these conditions are not regular expressions; they compare a variable to the regex after ??, or examine the exit status of an external command, respectively. There are a few other special conditions like this in Procmail; arguably, all of them are rather obscure.
Newcomers to shell scripting should also notice that each shell command pipeline has two distinct results: whatever is being printed on standard output, and, completely separate from that, an exit code which reveals whether or not the command completed successfully. (Conventionally, a zero exit status signals success, and anything else is an error. For example, the exit status from grep is 0 if it finds at least one match, 1 if it doesn't, and usually some other nonzero exit code if you passed in an invalid regular expression, or you don't have permission to read the input file, etc.)
For further details, perhaps see also http://www.iki.fi/era/procmail/ which has an old "mini-FAQ" which covers several of the topics here, and a "quick reference" for looking up details of the syntax.
I'm not familiar with Virtualmin but https://docs.virtualmin.com/Webmin/PostgreSQL_Database_Server shows how to set up Postgres and as per https://docs.virtualmin.com/Webmin/Procmail_Mail_Filter I guess you will want to use the option to put this code in an include file.
Is this an allowed "response" to an IMAP APPEND command? Sometimes the mailserver where I want to upload some messages responds this way and my current implementation does to allow the EXPUNGE.
A00003 APPEND "somefolder" (\Seen) "12-Dec-2012 12:12:12 +0000" {1212}
* 1 EXPUNGE
* 18 EXISTS
* 18 RECENT
+ send APPEND data...
What I have:
https://www.rfc-editor.org/rfc/rfc3501#section-7.4.1
An EXPUNGE response MUST NOT be sent when no command is in progress,
nor while responding to a FETCH, STORE, or SEARCH command.
Also:
A command is not "in progress" until the complete command
has been received; in particular, a command is not "in progress"
during the negotiation of command continuation.
I am not able to put the pieces together.
The server is behaving incorrectly. It should not send EXPUNGE and then the + continuation. That said, this rule
in particular, a command is not "in progress" during the
negotiation of command continuation
is a bit little senseless and I would not trust random servers to obey it.
I can guess why the rule exists. In a command like the one below, the meaning of 3:7 depends on which EXPUNGE responses the client has parsed and acted on before it constructed the string 3:7:
a uid search subject {3}
foo
3:7
But the server has to deal with MSNs. Clients can generally choose to avoid the whole problem area by using UIDs instead of MSNs.
My suggestion is to avoid sending MSNs, to use UIDs always, and to be as tolerant as you can of oddly timed EXPUNGE responses.
I already have an LDAP script in order to read LDAP user information one by one. My problem is that I am returning all users found in Active Directory. This will not work because currently our AD has around 100,000 users causing the script to crash due to memory limitations.
What I was thinking of doing was to try to process users by batches of X amount of users and if possible, using threads in order to process some users in parallel. The only thing is that I have just started using Perl, so I was wondering if anyone could give me a general idea of how to do this.
If you can get the executable ldapsearch to work in your environment (and it does work in *nix and Windows, although the syntax is often different), you can try something like this:
my $LDAP_SEARCH = "ldapsearch -h $LDAP_SERVER -p $LDAP_PORT -b $BASE -D uid=$LDAP_USERNAME -w $LDAP_PASSWORD -LLL";
my #LDAP_FIELDS = qw(uid mail Manager telephoneNumber CostCenter NTLogin displayName);
open (LDAP, "-|:utf8", "$LDAP_SEARCH \"$FILTER\" " . join(" ", #LDAP_FIELDS));
while (<LDAP>) {
# process each LDAP response
}
I use that to read nearly 100K LDAP entries without memory problems (although it still takes 30 minutes or more). You'll need to define $FILTER (or leave it blank) and of course all the LDAP server/username/password pieces.
If you want/need to do a more pure-Perl version, I've had better luck with Net::LDAP instead of Net::LDAP::Express, especially for large queries.
I'm using getmail + maildrop + mutt + msmtp chain with messages stored in Maildir. Very big inbox bothers me, so i wanted to organize mail by date like that:
Maildir
|-2010.11->all messages with "Date: *, * Nov 2010 *"
|-2010.12->same as above...
|-2011.01
`-2011.02
I've googled much and read about mailfilter language, but still it is hard for me to write such filter. Maildrop's mailing list archives has almost nothing on this (as far as i scanned through it). There is some semi-solution on https://unix.stackexchange.com/questions/3092/organize-email-by-date-using-procmail-or-maildrop, but i don't like it, because i want to use "Date:" header and i want to sort by month like "YEAR.MONTH" in digits.
Any help, thoughts, links, materials will be appreciated.
Using mostly man pages, I came up with the following solution for use on Ubuntu 10.04. Create a mailfilter file called, for example, mailfilter-archive with the following content:
DEFAULT="$HOME/mail-archive"
MAILDIR="$DEFAULT"
# Uncomment the following to get logging output
#logfile $HOME/tmp/maildrop-archive.log
# Create maildir folder if it does not exist
`[ -d $DEFAULT ] || maildirmake $DEFAULT`
if (/^date:\s+(.+)$/)
{
datefile=`date -d "$MATCH1" +%Y-%m`
to $DEFAULT/$datefile
}
# In case the message is missing a date header, send it to a default mail file
to $DEFAULT/inbox
This uses the date command, taking the date header content as input (assuming it is in RFC-2822 format) and producing a formatted date to use as the mail file name.
Then execute the following on existing mail files to archive your messages:
cat mail1 mail2 mail3 mail4 | reformail -s maildrop mailfilter-archive
If the mail-archive contents look good, you could remove the mail1, mail2, mail3, mail4, etc. mail files.