Re: CC all messages relayed through postfix
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 14 Dec 2010, at 02:31, Jerrale G wrote: > How would you store a CC of all mailings relayed through postfix, sent by our > users. We have plenty of logs but they dont tell us if someone sends spam and > how much, so that we may reprimand the user early before ending up on spam > lists. We could even use other third party software to track and collect the > mailings stored within the folders. We do require everyone to store messages > in their sent items but we do NOT traverse the users' mail folders for > privacy and they could also delete the spam messages, from the sent folder, > after sending. http://www.postfix.org/postconf.5.html#always_bcc Ronald R MacDonald : http://www.rmacd.com/ ron...@rmacd.com : +44-777-2351655 -BEGIN PGP SIGNATURE- Version: GnuPG/MacGPG2 v2.0.14 (Darwin) iEYEARECAAYFAk0HLzIACgkQg+87crce7IMNowCdGnNS80RwOR0hN32c/uLMEtks 1fUAn2MxrrwNIvPAmSfWPFVdJqTJeD9x =Ze2u -END PGP SIGNATURE-
Re: Append orig_to messages subject
Nobody ? seyazar wrote: > > Hi > > We have postfix server and some of our users have .forward file. I want ot > change orig_to mesages (forwarded mesages) subject in server side, Can I > do that > > thanks in advance > > selcuk > -- View this message in context: http://old.nabble.com/Append-orig_to-messages-subject-tp30443565p30449675.html Sent from the Postfix mailing list archive at Nabble.com.
modify messages subject forwarded mails by .forward
Hi We have postfix server and some of our users have .forward file. I want ot change orig_to mesages (forwarded mesages) subject in server side, Can I do that thanks in advance selcuk -- View this message in context: http://old.nabble.com/modify-messages-subject-forwarded-mails-by-.forward-tp30448906p30448906.html Sent from the Postfix mailing list archive at Nabble.com.
Re: How to extract information from postfix log through cron ?
On Mon, 13 Dec 2010 12:24:10 +0530 "J. Bakshi" wrote: > Hello postfix gurus, > > I have an email server built on postfix+dovecot+mysql (I have made it based > on ISP style mailserver available at net ) for our organization and the > system is running for more than 4 yrs. I like to arrange something which can > analyze the mail log everyday and send me an email at night about the total > mail send by different users, at what destination, the subject of the mail, > the bounce mail etc.. This is required for the internal record keeping of our > organization. Is there any linux based application which can do the same ? I > have a felling this can also be done with shell script, any idea ? > > Thanks for your time > > Any clue please ?
Re: Append orig_to messages subject
* selcukyazar : > > We have postfix server and some of our users have .forward file. I want ot > > change orig_to mesages (forwarded mesages) subject in server side, Can I > > do that So you want to change the Subject: line whenever a mail is being forwarded using a .forward file? Am I getting this right? -- Ralf Hildebrandt Geschäftsbereich IT | Abteilung Netzwerk Charité - Universitätsmedizin Berlin Campus Benjamin Franklin Hindenburgdamm 30 | D-12203 Berlin Tel. +49 30 450 570 155 | Fax: +49 30 450 570 962 ralf.hildebra...@charite.de | http://www.charite.de
Re: Append orig_to messages subject
Hi, yes. right. is it posssible for filter or another way. thanks you. selcuk. On Tue, Dec 14, 2010 at 11:29 AM, Ralf Hildebrandt < ralf.hildebra...@charite.de> wrote: > * selcukyazar : > > > > We have postfix server and some of our users have .forward file. I want > ot > > > change orig_to mesages (forwarded mesages) subject in server side, Can > I > > > do that > > So you want to change the Subject: line whenever a mail is being > forwarded using a .forward file? > > Am I getting this right? > > -- > Ralf Hildebrandt > Geschäftsbereich IT | Abteilung Netzwerk > Charité - Universitätsmedizin Berlin > Campus Benjamin Franklin > Hindenburgdamm 30 | D-12203 Berlin > Tel. +49 30 450 570 155 | Fax: +49 30 450 570 962 > ralf.hildebra...@charite.de | http://www.charite.de > > -- Selçuk YAZAR http://www.selcukyazar.blogspot.com
Re: Append orig_to messages subject
* Selcuk Yazar :
> Hi,
>
> yes. right. is it posssible for filter or another way.
Directly with .forward alone: No
But you can call procmail from .forward and do it that way (I guess)
You would need to use formail to extract the subject into a variable and
then use formail as a filter to update the Subject line
e.g.:
SUBJECT=formail -zx "Subject:":0fwh
| /usr/bin/formail -b -a -I"Subject: [prefix here]$SUBJECT"
| ${SENDMAIL} -i n...@address
I think.
--
Ralf Hildebrandt
Geschäftsbereich IT | Abteilung Netzwerk
Charité - Universitätsmedizin Berlin
Campus Benjamin Franklin
Hindenburgdamm 30 | D-12203 Berlin
Tel. +49 30 450 570 155 | Fax: +49 30 450 570 962
ralf.hildebra...@charite.de | http://www.charite.de
Re: Append orig_to messages subject
Thanks for prompt reply. also i try "| /usr/sbin/sendmail -i
myad...@gmail.com" but i think there is no way to change subject in here.
i will try procmail. thanks again.
selçuk
On Tue, Dec 14, 2010 at 11:39 AM, Ralf Hildebrandt <
ralf.hildebra...@charite.de> wrote:
> * Selcuk Yazar :
> > Hi,
> >
> > yes. right. is it posssible for filter or another way.
>
> Directly with .forward alone: No
> But you can call procmail from .forward and do it that way (I guess)
>
> You would need to use formail to extract the subject into a variable and
> then use formail as a filter to update the Subject line
>
> e.g.:
>
> SUBJECT=formail -zx "Subject:":0fwh
> | /usr/bin/formail -b -a -I"Subject: [prefix here]$SUBJECT"
> | ${SENDMAIL} -i n...@address
>
> I think.
>
> --
> Ralf Hildebrandt
> Geschäftsbereich IT | Abteilung Netzwerk
> Charité - Universitätsmedizin Berlin
> Campus Benjamin Franklin
> Hindenburgdamm 30 | D-12203 Berlin
> Tel. +49 30 450 570 155 | Fax: +49 30 450 570 962
> ralf.hildebra...@charite.de | http://www.charite.de
>
>
--
Selçuk YAZAR
http://www.selcukyazar.blogspot.com
Re: Append orig_to messages subject
* Selcuk Yazar : > Thanks for prompt reply. also i try "| /usr/sbin/sendmail -i > myad...@gmail.com" but i think there is no way to change subject in here. "| sed 's/Subject: foo/Subject: bar/g' | /usr/sbin/sendmail -i myad...@gmail.com" but Victor will probably flame me for this :) -- Ralf Hildebrandt Geschäftsbereich IT | Abteilung Netzwerk Charité - Universitätsmedizin Berlin Campus Benjamin Franklin Hindenburgdamm 30 | D-12203 Berlin Tel. +49 30 450 570 155 | Fax: +49 30 450 570 962 ralf.hildebra...@charite.de | http://www.charite.de
Re: Append orig_to messages subject
Thanks It works. :) i tried sed end of command :) selçuk. Ralf Hildebrandt wrote: > > * Selcuk Yazar : >> Thanks for prompt reply. also i try "| /usr/sbin/sendmail -i >> myad...@gmail.com" but i think there is no way to change subject in here. > > "| sed 's/Subject: foo/Subject: bar/g' | /usr/sbin/sendmail -i > myad...@gmail.com" > > but Victor will probably flame me for this :) > > -- > Ralf Hildebrandt > Geschäftsbereich IT | Abteilung Netzwerk > Charité - Universitätsmedizin Berlin > Campus Benjamin Franklin > Hindenburgdamm 30 | D-12203 Berlin > Tel. +49 30 450 570 155 | Fax: +49 30 450 570 962 > ralf.hildebra...@charite.de | http://www.charite.de > > > -- View this message in context: http://old.nabble.com/Append-orig_to-messages-subject-tp30443565p30453311.html Sent from the Postfix mailing list archive at Nabble.com.
selective behaviour for reject_sender_login_mismatch ?
I would like to be able to do "soft" or "hard" checks on sasl userid + sender domains depending on the sasl userid, i.e.: if userid=='customer1' then only log warnings on mismatch if userid=='customer2' then reject on mismatch I was thinking of creating two restrictions classes: soft = warn_if_reject,reject_sender_login_mismatch hard = reject_sender_login_mismatch but I can't find an access table that is indexed by sasl userid. Is there a way to do this without a policy server? /Per Jessen, Zürich
Re: verify db with mysql
On Tuesday, 7th of december 2010, 21:57:00 Wietse Venema wrote: > Wietse Venema: > > Thanks for the patch. > > > > Stefan Jakobs: > > > I'am not aware of any dead-lock issues. The sequence pseudo-thread > > > will query the database only once with the first key. For every > > > next key the sequence pseudo-thread is working with the results > > > in the memory. With a very large database the size of the response > > > may be a problem. But a INSERT/DELETE/UPDATE operation will not > > > conflict with the sequence pseudo-thread. Finally, I can not > > > prove if the code is dead-lock safe. > > > > It appears that this sequence() implementation uses memory in > > proportion to the database size. That is not acceptable. Would it > > be possible to maintain state with a limited amount of memory for > > a database cursor? > > > > By design, Postfix memory usage must not keep growing with increasing > > data size, queue size, message size, database size etc. This is > > necessary to ensure sane handling of overload. It is not acceptable > > that Postfix becomes deadlocked under overload. > > Looking over MySQL documentation, there appears to be a HANDLER > primitive that appears to support FIRST/NEXT sequential access > without using an amount of memory that grows with database size. > > http://dev.mysql.com/doc/refman/5.5/en/handler.html > http://dev.mysql.com/doc/refman/4.1/en/handler.html > > This approach seems to have similar consistency limitations as > other Postfix maps that support FIRST/NEXT sequential access while > database updates are happening, and that is not a problem. When > we use FIRST/NEXT for database cleanup, it is sufficient if we > clean up most of the stale entries. Great hint. I wasn't aware of the HANDLER primitive. I would have used mysql_use_result() but it would have needed its own connection to the server and would have made the code more complicated. I changed my code and it uses now the handler primitive. You will find the new patch against Postfix 2.7.1 in the appendix. The advantage is that the sequence() implemantation fetches only one data set (tuple) per query, so the used memory doesn't grow with the database size. A drawback is that this solution is not as configurable/flexible as the other one. And it's still the case that the first two values of a fetched tuple must be the address and its corresponing cache timings (data). But I guess that is acceptable. I'm not aware of any deadlock issues. But again, I can not prove it. With this new patch a configuration for using the verify db with mysql looks like this: /etc/postfix/verify.cf: user = postfix password = dbname = postfix cache_tblname = verify query = SELECT data FROM verify WHERE address='%s' delete = DELETE FROM verify WHERE address='%s' insert = INSERT verify SET address='%s', data='%v' update = UPDATE verify SET data='%v' WHERE address='%s' > Wietse Thank you for your help and suggestions. Kind regards Stefan diff -ur postfix-2.7.1.orig/man/man5/mysql_table.5 postfix-2.7.1/man/man5/mysql_table.5 --- postfix-2.7.1.orig/man/man5/mysql_table.5 2008-07-21 13:50:13.0 +0200 +++ postfix-2.7.1/man/man5/mysql_table.5 2010-12-11 20:39:20.0 +0100 @@ -126,6 +126,15 @@ .nf dbname = customer_database .fi +.IP "\fBcache_tblname\fR" +The name of the cache table. Postfix will perform cache cleanups +on this table. Example: +.nf +cache_tblname = verify +.fi +.IP +This parameter is available with Postfix MySQL write support patch. + .IP "\fBquery\fR" The SQL query template used to search the database, where \fB%s\fR is a substitute for the address Postfix is trying to resolve, @@ -191,6 +200,139 @@ parameter is not specified. NOTE: DO NOT put quotes around the query parameter. +.IP "\fBinsert\fR" +The SQL insert template used to insert a input key, value pair into the +database, where \fB%s\fR is a substitute for the input key and \fB%v\fR +is a substitute for the value, e.g. +.nf +insert = INSERT verify SET address='%s', data='%v' +.fi + +This parameter supports the following '%' expansions: +.RS +.IP "\fB\fB%%\fR\fR" +This is replaced by a literal '%' character. +.IP "\fB\fB%s\fR\fR" +This is replaced by the input key. +SQL quoting is used to make sure that the input key does not +add unexpected metacharacters. +.IP "\fB\fB%v\fR\fR" +This is replaced by the corresponding value. +SQL quoting is used to make sure that the value does not +add unexpected metacharacters. +.IP "\fB\fB%u\fR\fR" +When the input key is an address of the form u...@domain, \fB%u\fR +is replaced by the SQL quoted local part of the address. +Otherwise, \fB%u\fR is replaced by the entire search string. +If the localpart is empty, the insert is suppressed and returns +no results. +.IP "\fB\fB%d\fR\fR" +When the input key is an address of the form u...@domain, \fB%d\fR +is replaced by the SQL quoted domain part of the address. +Otherwise, the insert is suppressed and returns no results. +.IP "\f
Re: How to extract information from postfix log through cron ?
J. Bakshi put forth on 12/14/2010 3:27 AM: > On Mon, 13 Dec 2010 12:24:10 +0530 > "J. Bakshi" wrote: > >> Hello postfix gurus, >> >> I have an email server built on postfix+dovecot+mysql (I have made it based >> on ISP style mailserver available at net ) for our organization and the >> system is running for more than 4 yrs. I like to arrange something which can >> analyze the mail log everyday and send me an email at night about the total >> mail send by different users, at what destination, the subject of the mail, >> the bounce mail etc.. This is required for the internal record keeping of >> our organization. Is there any linux based application which can do the same >> ? I have a felling this can also be done with shell script, any idea ? >> >> Thanks for your time >> >> > > > Any clue please ? You already received a response, from me. Here it is, archived. I replied less than 30 minutes after your original post. Did you simply not see my reply? http://tech.groups.yahoo.com/group/postfix-users/message/271995 -- Stan
Re: selective behaviour for reject_sender_login_mismatch ?
Per Jessen: > I would like to be able to do "soft" or "hard" checks on sasl userid + > sender domains depending on the sasl userid, i.e.: > > if userid=='customer1' then only log warnings on mismatch > if userid=='customer2' then reject on mismatch > > I was thinking of creating two restrictions classes: > > soft = warn_if_reject,reject_sender_login_mismatch > hard = reject_sender_login_mismatch > > but I can't find an access table that is indexed by sasl userid. > > Is there a way to do this without a policy server? It would take very little code to add a check_sasluser_access feature (this would do only exact match - no substring magic such as parent domain or network subnet). But my own time is very limited. Wietse
Re: How to extract information from postfix log through cron ?
On Tue, 14 Dec 2010 06:05:50 -0600 Stan Hoeppner wrote: > J. Bakshi put forth on 12/14/2010 3:27 AM: > > On Mon, 13 Dec 2010 12:24:10 +0530 > > "J. Bakshi" wrote: > > > >> Hello postfix gurus, > >> > >> I have an email server built on postfix+dovecot+mysql (I have made it > >> based on ISP style mailserver available at net ) for our organization and > >> the system is running for more than 4 yrs. I like to arrange something > >> which can analyze the mail log everyday and send me an email at night > >> about the total mail send by different users, at what destination, the > >> subject of the mail, the bounce mail etc.. This is required for the > >> internal record keeping of our organization. Is there any linux based > >> application which can do the same ? I have a felling this can also be done > >> with shell script, any idea ? > >> > >> Thanks for your time > >> > >> > > > > > > Any clue please ? > > You already received a response, from me. Here it is, archived. I > replied less than 30 minutes after your original post. Did you simply > not see my reply? > > http://tech.groups.yahoo.com/group/postfix-users/message/271995 > Hello Stan, I am afraid to say but I really did not get the response mail. Any how now I can see the response following your link. Thanks a lot -- ** Registered Linux User 524244 //PERSON name: Joydeep Bakshi city: KOLKATA state: WEST BENGAL country: IN usage: Home, Work started: sep 2001 homepage: http://jbakshi.50webs.com *
Re: selective behaviour for reject_sender_login_mismatch ?
On Tue, Dec 14, 2010 at 07:10:01AM -0500, Wietse Venema wrote: > > but I can't find an access table that is indexed by sasl userid. > > > > Is there a way to do this without a policy server? > > It would take very little code to add a check_sasluser_access > feature (this would do only exact match - no substring magic such > as parent domain or network subnet). But my own time is very limited. The problem is that the SASL user name may well contain white-space, and postmap(1) cannot create indexed tables with keys that contain white-space. You could create the tables with other tools, but then you can't update the files "in place", you have to create a temporary indexed file and rename(2) it into place. This would work with CDB and Berkeley DB, but not with traditional "dbm" files, since you can't atomically rename two files. I am not sure that encoding the lookup key (quoted-printable?, xtext?, RFC 2047 if necessary?) is a particularly attractive option. -- Viktor.
Re: selective behaviour for reject_sender_login_mismatch ?
Victor Duchovni wrote: > On Tue, Dec 14, 2010 at 07:10:01AM -0500, Wietse Venema wrote: > >> > but I can't find an access table that is indexed by sasl userid. >> > >> > Is there a way to do this without a policy server? >> >> It would take very little code to add a check_sasluser_access >> feature (this would do only exact match - no substring magic such >> as parent domain or network subnet). But my own time is very limited. > > The problem is that the SASL user name may well contain white-space, > and postmap(1) cannot create indexed tables with keys that contain > white-space. You could create the tables with other tools, but then > you can't update the files "in place", you have to create a temporary > indexed file and rename(2) it into place. This would work with CDB > and Berkeley DB, but not with traditional "dbm" files, since you > can't atomically rename two files. Wouldn't this also be the case for smtpd_sender_login_maps ? /Per Jessen, Zürich
Re: selective behaviour for reject_sender_login_mismatch ?
On Tue, Dec 14, 2010 at 02:01:31PM +0100, Per Jessen wrote: > > The problem is that the SASL user name may well contain white-space, > > and postmap(1) cannot create indexed tables with keys that contain > > white-space. You could create the tables with other tools, but then > > you can't update the files "in place", you have to create a temporary > > indexed file and rename(2) it into place. This would work with CDB > > and Berkeley DB, but not with traditional "dbm" files, since you > > can't atomically rename two files. > > Wouldn't this also be the case for smtpd_sender_login_maps ? No, the sender is the lookup key. While white-space is also legal in email addresses, it is far less likely that an email address localpart will contain white-space. Perhaps we can ignore both potential issues... Does anyone (on this list) have SMTP SASL backends that support login names with white-space? Or know of sites that do? -- Viktor.
Re: Append orig_to messages subject
Ralf Hildebrandt:
[ Charset UTF-8 unsupported, converting... ]
> * Selcuk Yazar :
> > Hi,
> >
> > yes. right. is it posssible for filter or another way.
>
> Directly with .forward alone: No
> But you can call procmail from .forward and do it that way (I guess)
>
> You would need to use formail to extract the subject into a variable and
> then use formail as a filter to update the Subject line
>
> e.g.:
>
> SUBJECT=formail -zx "Subject:":0fwh
> | /usr/bin/formail -b -a -I"Subject: [prefix here]$SUBJECT"
> | ${SENDMAIL} -i n...@address
>
> I think.
I think this will cause a loop when forwarded mail bounces (hint:
you forgot to copy the sender envelope address).
Wietse
Re: verify db with mysql
Stefan: > A drawback is that this > solution is not as configurable/flexible as the other one. And it's still the > case that the first two values of a fetched tuple must be the address and its > corresponing cache timings (data). But I guess that is acceptable. Do you really mean that the implementation is usable only for the Postfix verify(8) database format? Have you tested this with query and update activity while a sequence operation is in progress? That is required by the Postfix dict_cache implementation. Wietse
Re: CC all messages relayed through postfix
On 12/13/2010 9:31 PM, Jerrale G wrote: > How would you store a CC of all mailings relayed through postfix, sent > by our users. We have plenty of logs but they dont tell us if someone > sends spam and how much, so that we may reprimand the user early before > ending up on spam lists. We could even use other third party software to > track and collect the mailings stored within the folders. We do require > everyone to store messages in their sent items but we do NOT traverse > the users' mail folders for privacy and they could also delete the spam > messages, from the sent folder, after sending. > > The idea is to keep a copy ourselves for reference and only be able to > reference the mailing by the queue id in the mail log; we dont want > other admins to be able to search for a specific user's mailings, > within the CC folder, by the originating user's email address or such, > which means we will have to obfuscate certain headers before storing in > the CC folder; for privacy and security, the only way any admin should > be able to track sent mail is by the queue id reported by the receiving > smtpd postmaster. If another remote postmaster says they are receiving > mail from our system, they may or may not include a copy as long as they > tell us the queue id(s), for privacy of their end user. > > Happy Holidays, > > Jerrale Gayle > SC Senior Admin > BCC'ing all of your user's email is unethical IMHO. Scan outgoing and incoming email for spam; done. That way you aren't compromising your users' private information nor possible security to your clients. -Matt
Re: CC all messages relayed through postfix
Matt Hayes wrote: On 12/13/2010 9:31 PM, Jerrale G wrote: How would you store a CC of all mailings relayed through postfix, sent by our users. We have plenty of logs but they dont tell us if someone sends spam and how much, so that we may reprimand the user early before ending up on spam lists. We could even use other third party software to track and collect the mailings stored within the folders. We do require everyone to store messages in their sent items but we do NOT traverse the users' mail folders for privacy and they could also delete the spam messages, from the sent folder, after sending. The idea is to keep a copy ourselves for reference and only be able to reference the mailing by the queue id in the mail log; we dont want other admins to be able to search for a specific user's mailings, within the CC folder, by the originating user's email address or such, which means we will have to obfuscate certain headers before storing in the CC folder; for privacy and security, the only way any admin should be able to track sent mail is by the queue id reported by the receiving smtpd postmaster. If another remote postmaster says they are receiving mail from our system, they may or may not include a copy as long as they tell us the queue id(s), for privacy of their end user. Happy Holidays, Jerrale Gayle SC Senior Admin BCC'ing all of your user's email is unethical IMHO. Scan outgoing and incoming email for spam; done. That way you aren't compromising your users' private information nor possible security to your clients. -Matt Not unethical or compromising private data. If the information can be sniffed unencrypted on the wire it is already compromised. Most email administrators already have access to mail stores where the same data is stored unencrypted. A company's mail server and storage is not for personal use and anyone sending e-mail they want to be private should not use public/unecrypted methods.
Re: CC all messages relayed through postfix
On Tue, 14 Dec 2010 09:21:29 -0500 Matt Hayes articulated: > BCC'ing all of your user's email is unethical IMHO. Scan outgoing and > incoming email for spam; done. That way you aren't compromising your > users' private information nor possible security to your clients. In certain locals, unless the user was informed that their mail would be archived, it might very well be illegal to do so. Scanning both incoming and outgoing mail would be a far better solution, and one that is currently used by several ISPs. -- Jerry ✌ postfix-u...@seibercom.net _ TO REPORT A PROBLEM see http://www.postfix.org/DEBUG_README.html#mail TO (UN)SUBSCRIBE see http://www.postfix.org/lists.html
Re: CC all messages relayed through postfix
On 12/14/10 4:04 PM, Randy Ramsdell wrote: Matt Hayes wrote: On 12/13/2010 9:31 PM, Jerrale G wrote: How would you store a CC of all mailings relayed through postfix, sent by our users. We have plenty of logs but they dont tell us if someone sends spam and how much, so that we may reprimand the user early before ending up on spam lists. We could even use other third party software to track and collect the mailings stored within the folders. We do require everyone to store messages in their sent items but we do NOT traverse the users' mail folders for privacy and they could also delete the spam messages, from the sent folder, after sending. The idea is to keep a copy ourselves for reference and only be able to reference the mailing by the queue id in the mail log; we dont want other admins to be able to search for a specific user's mailings, within the CC folder, by the originating user's email address or such, which means we will have to obfuscate certain headers before storing in the CC folder; for privacy and security, the only way any admin should be able to track sent mail is by the queue id reported by the receiving smtpd postmaster. If another remote postmaster says they are receiving mail from our system, they may or may not include a copy as long as they tell us the queue id(s), for privacy of their end user. Happy Holidays, Jerrale Gayle SC Senior Admin BCC'ing all of your user's email is unethical IMHO. Scan outgoing and incoming email for spam; done. That way you aren't compromising your users' private information nor possible security to your clients. -Matt Not unethical or compromising private data. If the information can be sniffed unencrypted on the wire it is already compromised. Most email administrators already have access to mail stores where the same data is stored unencrypted. A company's mail server and storage is not for personal use and anyone sending e-mail they want to be private should not use public/unecrypted methods. That is an unwarranted assumption. If the OP provides email hosting, then he is certainly bound by fairly strict privacy laws. Nothing in the above suggests this is solely for professional use. -- J.
Re: CC all messages relayed through postfix
Jeroen Geilman wrote: On 12/14/10 4:04 PM, Randy Ramsdell wrote: Matt Hayes wrote: BCC'ing all of your user's email is unethical IMHO. Scan outgoing and incoming email for spam; done. That way you aren't compromising your users' private information nor possible security to your clients. -Matt Not unethical or compromising private data. If the information can be sniffed unencrypted on the wire it is already compromised. Most email administrators already have access to mail stores where the same data is stored unencrypted. A company's mail server and storage is not for personal use and anyone sending e-mail they want to be private should not use public/unecrypted methods. That is an unwarranted assumption. If the OP provides email hosting, then he is certainly bound by fairly strict privacy laws. Nothing in the above suggests this is solely for professional use. You are correct and should have keep my point more narrow in purpose. But I meant to express something similar to... BCC'ing is not unethical unless you read all the mail. I could easily BCC all the users mail and simply maintain a copy. It is the same as having root access to the mail store which I think the OP does.
Re: CC all messages relayed through postfix
On 12/14/2010 11:43 AM, Randy Ramsdell wrote: > Jeroen Geilman wrote: >> On 12/14/10 4:04 PM, Randy Ramsdell wrote: >>> Matt Hayes wrote: >> BCC'ing all of your user's email is unethical IMHO. Scan outgoing and incoming email for spam; done. That way you aren't compromising your users' private information nor possible security to your clients. -Matt >>> >>> Not unethical or compromising private data. If the information can be >>> sniffed unencrypted on the wire it is already compromised. Most email >>> administrators already have access to mail stores where the same data >>> is stored unencrypted. A company's mail server and storage is not for >>> personal use and anyone sending e-mail they want to be private should >>> not use public/unecrypted methods. >> That is an unwarranted assumption. If the OP provides email hosting, >> then he is certainly bound by fairly strict privacy laws. >> Nothing in the above suggests this is solely for professional use. >> > > You are correct and should have keep my point more narrow in purpose. > But I meant to express something similar to... BCC'ing is not unethical > unless you read all the mail. I could easily BCC all the users mail and > simply maintain a copy. It is the same as having root access to the mail > store which I think the OP does. My point is more along the lines of "Why would you need to see email to ensure that your users aren't sending out spam?" That's a ludicrous reason to pose. If you have reports that a user is sending spam, turn them off. Reading email to see if they are sending spam is just out right unethical imho. Most email, albeit not completely 'secure', is assumed by the client to be 'protected' from prying eyes once it is sent or received. There's no reason to go digging through a user's personal life, which email is to most, just to prove they aren't sending spam. -Matt
Re: CC all messages relayed through postfix
On 12/14/10 5:43 PM, Randy Ramsdell wrote: Jeroen Geilman wrote: On 12/14/10 4:04 PM, Randy Ramsdell wrote: Matt Hayes wrote: BCC'ing all of your user's email is unethical IMHO. Scan outgoing and incoming email for spam; done. That way you aren't compromising your users' private information nor possible security to your clients. -Matt Not unethical or compromising private data. If the information can be sniffed unencrypted on the wire it is already compromised. Most email administrators already have access to mail stores where the same data is stored unencrypted. A company's mail server and storage is not for personal use and anyone sending e-mail they want to be private should not use public/unecrypted methods. That is an unwarranted assumption. If the OP provides email hosting, then he is certainly bound by fairly strict privacy laws. Nothing in the above suggests this is solely for professional use. You are correct and should have keep my point more narrow in purpose. But I meant to express something similar to... BCC'ing is not unethical unless you read all the mail. I could easily BCC all the users mail and simply maintain a copy. It is the same as having root access to the mail store which I think the OP does. Except that he explicitly listed "scanning the mail to see if it was spam" as the REASON to BCC. Unethical, yup. -- J.
Scripting changing sending MTA
This is on a Fedora system. In the Postfix install documentation I found that I need to do the following: /usr/sbin/alternatives --config mta And select '2' to switch to Postfix. Is there a way to put this into an install script? Something simple like: echo 2| /usr/sbin/alternatives --config mta ???
Re: Scripting changing sending MTA
On 12/14/10 6:44 PM, Robert Moskowitz wrote: This is on a Fedora system. In the Postfix install documentation I found that I need to do the following: /usr/sbin/alternatives --config mta And select '2' to switch to Postfix. Is there a way to put this into an install script? Something simple like: echo 2| /usr/sbin/alternatives --config mta ??? Why not ask it on a Fedora-related forum ? It has nothing to do with postfix, after all. -- J.
Re: Scripting changing sending MTA
On 12/14/2010 12:44 PM, Robert Moskowitz wrote: > This is on a Fedora system. > > In the Postfix install documentation I found that I need to do the > following: > > /usr/sbin/alternatives --config mta > > And select '2' to switch to Postfix. > > Is there a way to put this into an install script? > > Something simple like: > > echo 2| /usr/sbin/alternatives --config mta > > ??? > > That is a Fedora-specific setting, nothing to do with Postfix itself. You'll want to consult Fedora documentation etc. -Matt
Re: verify db with mysql
On Tuesday 14 December 2010 14:43:23 Wietse Venema wrote: > Stefan: > > A drawback is that this > > solution is not as configurable/flexible as the other one. And it's still > > the case that the first two values of a fetched tuple must be the > > address and its corresponing cache timings (data). But I guess that is > > acceptable. > > Do you really mean that the implementation is usable only for the > Postfix verify(8) database format? Sorry, my describtion wasn't clear. No, the implementation isn't bound to the verify(8) database format. The dict_mysql_sequence() function will return any key-value pair, as demanded by the interface. But the mysql HANDLER NEXT call will return a complete row of the table as an array. And the first element of this array must be the key and the second element must be the value. So the implementation of dict_mysql_sequence() expects the database to be in a specifc format, e.g (key|data|...). > Have you tested this with query and update activity while a sequence > operation is in progress? That is required by the Postfix dict_cache > implementation. Yes, I have tested that and it worked without problems. If you are interested then I will send you the logs of that test. > Wietse Regards Stefan
Re: verify db with mysql
Stefan Jakobs: > > On Tuesday 14 December 2010 14:43:23 Wietse Venema wrote: > > Stefan: > > > A drawback is that this > > > solution is not as configurable/flexible as the other one. And it's still > > > the case that the first two values of a fetched tuple must be the > > > address and its corresponing cache timings (data). But I guess that is > > > acceptable. > > > > Do you really mean that the implementation is usable only for the > > Postfix verify(8) database format? > > Sorry, my describtion wasn't clear. > No, the implementation isn't bound to the verify(8) database format. The > dict_mysql_sequence() function will return any key-value pair, as demanded by > the interface. But the mysql HANDLER NEXT call will return a complete row of > the table as an array. And the first element of this array must be the key > and > the second element must be the value. So the implementation of > dict_mysql_sequence() expects the database to be in a specifc format, e.g > (key|data|...). OK, that is not too restrictive, just a matter of documentation. > > Have you tested this with query and update activity while a sequence > > operation is in progress? That is required by the Postfix dict_cache > > implementation. > > Yes, I have tested that and it worked without problems. If you > are interested then I will send you the logs of that test. Yes, it would help when I want to run some tests (the results should be similar). One more question: what happens if a "first" sequence operation is requested before the last one is finished? Should the code maintain an internal flag that the "handler open" is still in effect, and do the "right" thing when another "first" sequence operation is requested? Wietse Wietse
Re: Scripting changing sending MTA
On 12/14/2010 01:08 PM, Jeroen Geilman wrote: On 12/14/10 6:44 PM, Robert Moskowitz wrote: This is on a Fedora system. In the Postfix install documentation I found that I need to do the following: /usr/sbin/alternatives --config mta And select '2' to switch to Postfix. Is there a way to put this into an install script? Something simple like: echo 2| /usr/sbin/alternatives --config mta ??? Why not ask it on a Fedora-related forum ? It has nothing to do with postfix, after all. Oh. I guess I did not think this through well enough. Figured MTA selection and postfix install instructions. Should have done the next step of for Fedora. Have a good day.
Re: Scripting changing sending MTA
Le 14/12/2010 18:44, Robert Moskowitz a écrit : This is on a Fedora system. In the Postfix install documentation I found that I need to do the following: /usr/sbin/alternatives --config mta And select '2' to switch to Postfix. Is there a way to put this into an install script? Something simple like: echo 2| /usr/sbin/alternatives --config mta ??? that's redhat installation process. someday, they'll provide /usr/sbin/alternatives --os netbsd :)
trouble with postscreen
uname -a FreeBSD 7.2-RELEASE FreeBSD 7.2-RELEASE postconf mail_version mail_version = 2.8-20101108 master.cf smtpd pass - - n - - smtpd -v smtp inet n - n - 1 postscreen -v dnsblog unix - - n - 0 dnsblog -v main.cf: postconf -n | egrep postscreen postscreen_bare_newline_action = enforce postscreen_bare_newline_enable = yes postscreen_blacklist_action = drop postscreen_cache_map = btree:$data_directory/ps_cache postscreen_dnsbl_action = drop postscreen_dnsbl_sites = zen.spamhaus.org, b.barracudacentral.org, truncate.gbudb.net postscreen_greet_action = drop postscreen_greet_banner = $smtpd_banner postscreen_greet_wait = 2s postscreen_non_smtp_command_action = enforce postscreen_non_smtp_command_enable = yes postscreen_pipelining_action = enforce postscreen_pipelining_enable = yes postscreen_whitelist_networks = $mynetworks, maillog: Dec 14 15:31:31 mydomain postfix/postfix-script[28743]: starting the Postfix mail system Dec 14 15:31:31 mydomain postfix/master[28744]: daemon started -- version 2.8-20101108, configuration /usr/local/etc/postfix Dec 14 15:31:31 mydomain postfix/qmgr[28746]: warning: bounce_queue_lifetime is larger than maximal_queue_lifetime - adjusting bounce_queue_lifetime Dec 14 15:31:32 mydomain postfix/postscreen[28752]: name_mask: ipv4 Dec 14 15:31:32 mydomain postfix/postscreen[28752]: inet_addr_local: configured 2 IPv4 addresses Dec 14 15:31:32 mydomain postfix/postscreen[28752]: process generation: 10 (10) Dec 14 15:31:32 mydomain postfix/postscreen[28752]: set_eugid: euid 125 egid 125 Dec 14 15:31:32 mydomain postfix/postscreen[28752]: Compiled against Berkeley DB version 1 Dec 14 15:31:33 mydomain postfix/master[28744]: warning: process /usr/local/libexec/postfix/postscreen pid 28752 exit status 1 Dec 14 15:31:33 mydomain postfix/master[28744]: warning: /usr/local/libexec/postfix/postscreen: bad command startup -- throttling Len
Re: trouble with postscreen
On Tue, Dec 14, 2010 at 10:43:02PM +0100, Len Conrad wrote: > uname -a > FreeBSD 7.2-RELEASE FreeBSD 7.2-RELEASE > > postconf mail_version > mail_version = 2.8-20101108 When running snapshots, and testing brand-new features of those snapshots, you must at least upgrade to the latest version before reporting a problem. The latest is currently 2.8-20101210. -- Viktor.
Re: trouble with postscreen
1) Leave verbose logging TURNED OFF. 2) Run the current Postfix snapshot. Wietse
call scripts for each of the incoming emails
hi everything, I met a problem recently because we need to add a new function to our product. the problem is for each valid incoming email, we need to call a script to insert it to different databases, someone said I could add this to the /etc/aliases, like : b...@example.org: "|/tmp/somescripts.sh", but it's only used for special users, unable for all the users(or emails) what should I do? do you have any suggestions? -- *Space Lee*
Re: call scripts for each of the incoming emails
On 15/12/2010, at 2:21 PM, Spacelee wrote: > hi everything, I met a problem recently because we need to add a new function > to our product. > the problem is for each valid incoming email, we need to call a script to > insert it to different databases, someone said I could add this to the > /etc/aliases, like : b...@example.org: "|/tmp/somescripts.sh", but it's only > used for special users, unable for all the users(or emails) > > what should I do? do you have any suggestions? At the risk of being blacklisted on this rather "robust" forum, when I've needed a DB backend for mail I've invariably ended up with a product designed for that purpose. The idea of piping or scripting may seem desirable at first, but as mail volume increases the overhead becomes unmanageable (I've attempted this approach with sendmail/exim/postfix/qmail and none performed adequately under heavy mail load whilst trying to pump into a DB). Whilst this isn't necessarily prescriptive of anyone else's situation, it is most certainly descriptive of my experience. It's quite possible that what you want and what I've attempted in the past are quite different :) Maybe look at DBmail - http://www.dbmail.org/ ? Asbestos suit on. James smime.p7s Description: S/MIME cryptographic signature
