procmail setup and multiple email addresses?

[gtwrek]

Ok, I've searched the forums here, and I see similar issues, but no concrete solutions.

I've got multiple sonic email addresses. I'd like to setup procmail for some of them. My needs are fairly sparse - I could live with each email address using the same procmail recipes.

I've got one shell account. I've setup and verified a .procmailrc for that account. Other postings on the forums indicate I can call up support have them create a symbolic link from the "other" email addresses to my one .procmailrc (Since I don't have shell accounts for the other email addresses).

My problem is in creating the "shared" assignment statements in my .procmailrc.

I wasn't able to "redirect" via a variable the location of my MAILDIR folder i.e. this did NOT work:
MAILDIR=$MAIL

$MAIL does exist in my shell environment, but under whatever process procmail is run, it's not set.
So, I had to hardcode my MAILDIR:
MAILDIR=/var/spool/mail/nn/mm/name/

This works, but of course for only the one email address. The "shared" .procmailrc would fail for the other email addresses (plus I don't even know the "nn/mm" directory for the other emails - although I'm sure support could help me)

Any pointers?

Thanks,

Mark

[cdkeen]

Hello,
I can confirm that when logged into shell.sonic.net as gtwrek your environment variables are set for $HOME and $MAIL; you can confirm this when logged in by entering the command 'env' into the shell. If you remove from your .procmailrc file the definitions for MAILDIR and DEFAULT and change LOGFILE to equal $HOME/log.`date +%y-%m-%d` instead of $MAILDIR, then I could create a symlink to .procmailrc for you in the home folder for each mailbox on your account (that you would like included) and you should be good to go. Just let me know how you want to proceed and I would be glad to assist! Thanks for choosing Sonic.net!

[cdkeen]

OK, you should be all set! Let me know if you need additional assistance.

[gtwrek]

Doesn't seem to be working (other than from my main gtwrek email).
The other email addresses don't seem to be picking up the .procmailrc.

Sortof hard to debug, as I can't see the logfile for the other accounts. And it appears that the procmail default of no logfile define = send email back to sender is turned off?

[cdkeen]

I see you are right, sorry about that! The symlinks won't work because the mailbox user does not have permissions to read/execute anything in another user's home directory. I went ahead and removed the symlinks and copied your .procmailrc to each mailbox (I modified them to use $HOME instead of a hard coded path). I do not mind helping you get set up how you would like, and if you need additional assistance feel free to post here or email to support@sonic.net, just put attn:cdkeen. Thanks!

[gtwrek]

Thanks - I can confirm it's working now.

I was afraid of the problems that we've had. Anyone else care to offer alternatives?

My options right now:
1. Call/email sonic support every time I wish to change my .procmailrc on my non-shell account emails.

2. Have sonic activate shell accounts for all my sonic email addresses. For the sole purpose of maintaining a .procmailrc.

Any other options? Some other posts on the sonic forums seems to imply other solutions, but nothing concrete.

I'll need to tweak them already (had it setup the way it was for testing), but it's not critical, so ok for now.

Thanks,

Mark

[cdkeen]

Sorry, you can't activate shell access for a mailbox account. Also, it is possible that in the future we may move away from procmail and recommend client side filtering instead, which is in part why the options are limited.

[gtwrek]

Well that removes one option, leaving me with just nagging sonic support everytime I need to tweak procmailrc settings.

Not ideal.

Please have your team reconsider the idea of moving away from procmail and other server side filtering.
Client-side filtering, well sucks. And there's too much variance. I access my sonic email from tons of different devices. All with there own ecosystems for mail filtering. (Apple device options are really bad/non-existent). And I'm tired of maintaining the same filtering (with often different rules) on all my access points...

Having this server side is much cleaner, IMHO.

I still don't understand why the symbolic link didn't work.
All the parent directories to my .procmailrc are: drwx--x--x,
so everyone ("others") should be able to get into the directory.
And my .procmailrc is readable by everyone: -rw-r--r--

Why can't procmail see it for the other users?

Thanks,

Mark

[darrylo]

Also, it is possible that in the future we may move away from procmail and recommend client side filtering instead, which is in part why the options are limited.

I understand that you really can't enhance procmail, but please keep the existing functionality (what little there is). Client-side filtering really sucks, as that assumes that clients can do filtering (iPhones and iPads suck at this).

[kgc]

There's a few things at play here including scale out of traditional unix user environments. But, what is more likely to force this issue than anything else is the desired to migrate to a modern mailbox format like dbox which would require us to use the dovecot lda. In doing so, we'd likely support sieve on the server side but there's quite a bit of functionality lost.