Re: Indiscriminate maildir processing
On 1/30/2012 9:10 AM, Eric Chandler wrote: The above simple example catches *EVERYTHING* and is suitable to be used in a lab or test setting. This is consistent with the initial request as I understand it. If the request was incomplete, it should be clarified. Yes, I want to catch everything. The dev/qa environments use different MTAs than production. The two environments contain approximately 1,500 linux/solaris hosts and, although they all run postfix, I don't have control over their applications that utilize it. Basically, it's BECAUSE they've had a bad history of flooding our corporate exchange servers with garbage that I want to create a place to store all emails they send, at-least long enough for those who want to see what they created can read them, before they are summarily-deleted automatically. It's partially a punishment to them for their lack of understanding of what emails can do to other systems, and partially to protect Exchange from filling up with garbage. My hope is that I could create a separate maildir for each recipient, no-matter if the recipient has a standard corporate email address, or even r...@postfix.org for all intents and purposes. I could easily write a cron to go down through all the maildirs and cull old stuff older than say a week. People who want to see what the emails contain could then imap in as whatever userid they want (another area for me to figure out - passwordless-imapd) and see those emails. Eric, have you looked at Enkive? It may give you much of what you're looking for, right down to user-less, or single user login, with access to everything. Albeit with a search interface instead of an IMAP MUA, which may actually be better given the test nature of mails being dumped into the sink. Check out the interactive demo and hit the search page to see the search parameter box. http://www.enkive.org/ http://wiki.enkive.org/index.php/Installation_Instructions http://wiki.enkive.org/index.php/GettingMailIntoEnkive I've not used it myself yet but it seems to have some nice features that lend it to uses other than strictly archiving. Uses Postfix as the MTA to get mail dumped into it. -- Stan
RE: Indiscriminate maildir processing
From: owner-postfix-us...@postfix.org [mailto:owner-postfix-us...@postfix.org] On Behalf Of Stan Hoeppner Sent: Tuesday, January 31, 2012 6:06 AM To: postfix-users@postfix.org Subject: Re: Indiscriminate maildir processing Eric, have you looked at Enkive? It may give you much of what you're looking for, right down to user-less, or single user login, with access to everything. Albeit with a search interface instead of an IMAP MUA, which may actually be better given the test nature of mails being dumped into the sink. Check out the interactive demo and hit the search page to see the search parameter box. http://www.enkive.org/ Thanks Stan! As it turns out, I've already coded the milter and it works swimmingly. I'm just now to the imap side of things to see what options I have there. I already have a rather-complicated milter system in place that grabs email information/contents for all emails we send and stores them in a massive Oracle database. We send about 40 million emails a month through postfix and these milters, and have over a billion emails saved in the database currently. What I'm doing with this little catch-all system is simply stopping dev/qa emails from getting into inboxes either internally or externally, with the option of people being able to look at the email and headers together in the sent mail, rather than running queries against the database. Looks like I have such a system now. Thanks for all the help everyone.
RE: Indiscriminate maildir processing
The above simple example catches *EVERYTHING* and is suitable to be used in a lab or test setting. This is consistent with the initial request as I understand it. If the request was incomplete, it should be clarified. Yes, I want to catch everything. The dev/qa environments use different MTAs than production. The two environments contain approximately 1,500 linux/solaris hosts and, although they all run postfix, I don't have control over their applications that utilize it. Basically, it's BECAUSE they've had a bad history of flooding our corporate exchange servers with garbage that I want to create a place to store all emails they send, at-least long enough for those who want to see what they created can read them, before they are summarily-deleted automatically. It's partially a punishment to them for their lack of understanding of what emails can do to other systems, and partially to protect Exchange from filling up with garbage. My hope is that I could create a separate maildir for each recipient, no-matter if the recipient has a standard corporate email address, or even r...@postfix.org for all intents and purposes. I could easily write a cron to go down through all the maildirs and cull old stuff older than say a week. People who want to see what the emails contain could then imap in as whatever userid they want (another area for me to figure out - passwordless-imapd) and see those emails. Thanks, Eric
Re: Indiscriminate maildir processing
On 1/30/2012 9:10 AM, Eric Chandler wrote: My hope is that I could create a separate maildir for each recipient, no-matter if the recipient has a standard corporate email address, or Creating wildcard users is more complicated. You can easily wildcard virtual domains with virtual_mailbox_domains = static:all but wildcarding virtual users is trickier since you can't use $N substitution in virtual_mailbox_maps. I expect you could use a *sql map for the mailbox maps and structure your query so it returns an answer for every user, but I can't help with that. imap in as whatever userid they want (another area for me to figure out - passwordless-imapd) and see those emails. dovecot master user feature, or a sql query in the auth backend that uses the same password for everybody. -- Noel Jones
RE: Indiscriminate maildir processing
Ok, I think for me the easiest way will be to simply port it out to a milter to do the job and simply discard the message. I'm very good a milter code, so that will probably allow me to do all sorts of special stuff on top of what I would eventually get out of postfix configuration magic, given the oddball task I'm trying to accomplish. Thanks for everyone's help. Eric Chandler Systems Architect -Original Message- From: owner-postfix-us...@postfix.org [mailto:owner-postfix-us...@postfix.org] On Behalf Of Noel Jones Sent: Monday, January 30, 2012 10:34 AM To: postfix-users@postfix.org Subject: Re: Indiscriminate maildir processing On 1/30/2012 9:10 AM, Eric Chandler wrote: My hope is that I could create a separate maildir for each recipient, no-matter if the recipient has a standard corporate email address, or Creating wildcard users is more complicated. You can easily wildcard virtual domains with virtual_mailbox_domains = static:all but wildcarding virtual users is trickier since you can't use $N substitution in virtual_mailbox_maps. I expect you could use a *sql map for the mailbox maps and structure your query so it returns an answer for every user, but I can't help with that. imap in as whatever userid they want (another area for me to figure out - passwordless-imapd) and see those emails. dovecot master user feature, or a sql query in the auth backend that uses the same password for everybody. -- Noel Jones
Re: Indiscriminate maildir processing
On 1/27/2012 12:40 PM, Eric Chandler wrote: Hello, We have a QA department that loves to send out email blasts that kill our Exchange servers for periods of time, and once in a while, will accidentally email a customer or 10,000 with a test message because they forgot to scrub their test database clones prior to running their test. Because of this, I want to set up a server to basically answer for absolutely any email sent to it and create a maildir mailbox in a humungous filesystem. I would also plan in writing a cron to delete all emails older than a week, and allow users to imap in and grab what they want to see. Currently, I have a QA system to handle some generic mailboxes used by dev/qa, but I would like to try and expand this postfix installation to just accept all mail indiscriminately. Can this be done? An easy capture everything alias would look like: # main.cf virtual_alias_maps = pcre:/etc/postfix/virtual_all.pcre # virtual_all.pcre /^/ someuser@somehost where someuser is a valid user on the domain somehost. somehost could be localhost.localdomain (also listed in mydestination), or some other destination. Search the mail list archives for further examples. -- Noel Jones
Re: Indiscriminate maildir processing
On 1/27/2012 6:34 PM, Stan Hoeppner wrote: On 1/27/2012 4:30 PM, Noel Jones wrote: On 1/27/2012 12:40 PM, Eric Chandler wrote: We have a QA department that loves to send out email blasts that kill our Exchange servers for periods of time, and once in a while, will accidentally email a customer or 10,000 with a test message because they forgot to scrub their test database clones prior to running their test. Because of this, I want to set up a server to basically answer for absolutely any email sent to it and create a maildir mailbox in a humungous filesystem. I would also plan in writing a cron to delete all emails older than a week, and allow users to imap in and grab what they want to see. Currently, I have a QA system to handle some generic mailboxes used by dev/qa, but I would like to try and expand this postfix installation to just accept all mail indiscriminately. Can this be done? An easy capture everything alias would look like: # main.cf virtual_alias_maps = pcre:/etc/postfix/virtual_all.pcre # virtual_all.pcre /^/ someuser@somehost where someuser is a valid user on the domain somehost. somehost could be localhost.localdomain (also listed in mydestination), or some other destination. Does this assume the Postfix server in question is an outbound relay for the Exchange server? If so wouldn't the OP need to add a sender address test to the catch all logic, lest break his mail system for all traffic? The above simple example catches *EVERYTHING* and is suitable to be used in a lab or test setting. This is consistent with the initial request as I understand it. If the request was incomplete, it should be clarified. -- Noel Jones
