Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss
Database import of user-submitted mail
0 views
Skip to first unread message
Fabio Sangiovanni
Feb 8, 2012, 4:19:36 AM2/8/12
to
Hello list,
my apologies in advance for the almost OT question.
I need to setup a mail server that does a particular thing: it receives mail (from user SMTP submission, not as final destination) and, instead of relay, "does something" that ends up in having the mail (body + headers + attachments) in a mysql table.
The ideal thing would be some mta that keeps the mail spool directly on a database backend; knowing that this is generally unwanted because of performance and reliability issues (and thus, rightfully, never implemented, specially in Postfix), I'm trying to figure out a way to get the same result.
Note: strict realtime is NOT a requirement (I'm allowed to do some sort of processing between mail arriving and its insertion in the database).
After a couple of days of brainstorming, I came to a conclusion that relies on Postfix and on some coding: using the after-queue filtering capabilities of Postfix, I would first dump the mail (flat file) in a directory (with a slightly modified version of this bash script: http://www.postfix.org/FILTER_README.html#simple_filter); then, using a cronjob scheduled every, let's say, 5 minutes, invoke some (php? ruby? perl?) script that does the batch import task "out of band" and removes the dump file.
I think that this "decouple" thing should give robustness to the whole process, providing small and single-task scripts for dump and import phases; it should be the "unix way" of doing things right :)
How would you accomplish the task? Can you think of some better solution?
Please correct me if I'm wrong in something.
Thank you!
Fabio
my apologies in advance for the almost OT question.
I need to setup a mail server that does a particular thing: it receives mail (from user SMTP submission, not as final destination) and, instead of relay, "does something" that ends up in having the mail (body + headers + attachments) in a mysql table.
The ideal thing would be some mta that keeps the mail spool directly on a database backend; knowing that this is generally unwanted because of performance and reliability issues (and thus, rightfully, never implemented, specially in Postfix), I'm trying to figure out a way to get the same result.
Note: strict realtime is NOT a requirement (I'm allowed to do some sort of processing between mail arriving and its insertion in the database).
After a couple of days of brainstorming, I came to a conclusion that relies on Postfix and on some coding: using the after-queue filtering capabilities of Postfix, I would first dump the mail (flat file) in a directory (with a slightly modified version of this bash script: http://www.postfix.org/FILTER_README.html#simple_filter); then, using a cronjob scheduled every, let's say, 5 minutes, invoke some (php? ruby? perl?) script that does the batch import task "out of band" and removes the dump file.
I think that this "decouple" thing should give robustness to the whole process, providing small and single-task scripts for dump and import phases; it should be the "unix way" of doing things right :)
How would you accomplish the task? Can you think of some better solution?
Please correct me if I'm wrong in something.
Thank you!
Fabio
Simone Caruso
Feb 8, 2012, 6:52:57 AM2/8/12
to
On 08/02/2012 10:19, Fabio Sangiovanni wrote:
> it receives mail (from user SMTP submission, not as final destination) and, instead of relay, "does something" that ends up in having the mail (body + headers + attachments) in a mysql table
You can write a custom 'deliver' that copies your emails into a different
> it receives mail (from user SMTP submission, not as final destination) and, instead of relay, "does something" that ends up in having the mail (body + headers + attachments) in a mysql table
storage (es. mysql), or use dbmail.
--
Simone Caruso
IT Consultant
+39 349 65 90 805
Fabio Sangiovanni
Feb 8, 2012, 9:16:11 AM2/8/12
to
Hi, thank you for your reply.
The point here is that I don't want to store messages that I receive as final destination, but those that, in a "normal" situation, I would act as a relay for. My scenario is the following:
internet -> mta for user submission (smtp) -> sql backend
The mta isn't configured to be the final destination for the messages: it's intended to accept mail (of course with authentication) and to store it in a sql backend instead of contacting remote MXs. Ideally, I would need an "SMTP to DB" converter, something more similar to a spool storage on database.
Thanks again,
Fabio
The point here is that I don't want to store messages that I receive as final destination, but those that, in a "normal" situation, I would act as a relay for. My scenario is the following:
internet -> mta for user submission (smtp) -> sql backend
The mta isn't configured to be the final destination for the messages: it's intended to accept mail (of course with authentication) and to store it in a sql backend instead of contacting remote MXs. Ideally, I would need an "SMTP to DB" converter, something more similar to a spool storage on database.
Thanks again,
Fabio
Simone Caruso
Feb 8, 2012, 10:45:24 AM2/8/12
to
On 08/02/2012 15:16, Fabio Sangiovanni wrote:
> but those that, in a "normal" situation, I would act as a relay for.
You can redirect them to 'your daemon' with 'relayhost' or with a specific
> but those that, in a "normal" situation, I would act as a relay for.
transport map.
0 new messages