Enforcing line length limit for locally delivered mail
Hello, were running a few mailing lists with news gateway using postfix for the MTA. So the setup is like this: postfix -> mailman -> innd Now the problem is that sometimes mails exceeding the 1000 characters line limit are handed over to postfix, which happily forwards them to mailman which in turn sends them to innd, and innd rejects them because the lines are longer than 998 characters. So is it possible to get postfix to do the SMPT line length limit handling (split long lines and insert CR LF ) for this kind of setup? TIA, Markus
statistics about use of webmail
Hi guys My boss said me to know the statistics about use of webmail, exactly which users used webmail during a week. Any of yours know how to make it? Im using Postfix + Dovecot + openldap + rouncube. If you need more info please comment me. Thanks!!
Re: Enforcing line length limit for locally delivered mail
Markus Sch?pflin: > Hello, > > were running a few mailing lists with news gateway using postfix for the > MTA. So the setup is like this: postfix -> mailman -> innd > > Now the problem is that sometimes mails exceeding the 1000 characters line > limit are handed over to postfix, which happily forwards them to mailman > which in turn sends them to innd, and innd rejects them because the lines > are longer than 998 characters. > > So is it possible to get postfix to do the SMPT line length limit handling > (split long lines and insert CR LF ) for this kind of setup? Perhaps surprisingly, Postfix enforces the SMTP line length limit only delivery via SMTP. Use a NULL content filter. See FILTER_README, advanced example, and connect the Postfix SMTP client directly with a Postfix SMTP server on 127.0.0.1:10025. Wietse
Re: statistics about use of webmail
On 12/16/2010 5:06 AM, deconya wrote: Hi guys My boss said me to know the statistics about use of webmail, exactly which users used webmail during a week. Any of yours know how to make it? Im using Postfix + Dovecot + openldap + rouncube. If you need more info please comment me. Thanks!! You'll need to check the roundcube and apache logs to see who is using the webmail system.
Re: statistics about use of webmail
awstats will show stats from maillog or httpd log format. Not hard to setup, creates pretty graphs. it will show dns names, but im not sure if it will pull user info from logfiles. Quoting Noel Jones : On 12/16/2010 5:06 AM, deconya wrote: Hi guys My boss said me to know the statistics about use of webmail, exactly which users used webmail during a week. Any of yours know how to make it? Im using Postfix + Dovecot + openldap + rouncube. If you need more info please comment me. Thanks!! You'll need to check the roundcube and apache logs to see who is using the webmail system. -- Dwayne Hottinger Network Administrator Harrisonburg City Public Schools "Everything should be made as simple as possible, but not simpler." -- Albert Einstein "The hottest places in Hell are reserved for those who, in times of moral crisis, preserved their neutrality." -- Dante
Re: postfix and mailing the same e-mail to hundreds of clients
On 12/15/2010 03:24 AM, Razvan Chitu wrote: Hello there, The question here is a fairly simple one: given a simple postfix mail server (primary mx), with local *nix user accounts, I want to know the best way of implementing the following situation: - Someone (a.k.a. the management) sends an e-mail with attachments to a certain e-mail address on this server from the internal network (let's say service_clie...@mydomain.com) and they want this e-mail relayed to some hundred (less than a thousand) e-mail addresses. Definitely mailman. Very easy to integrate with Postfix. I am running them on a Fedora system. I am not that heavy of a linux tech and got it all working.
Re: Load issues with Postfix on FreeBSD
Wietse Venema: > Victor Duchovni: > > On Wed, Dec 15, 2010 at 01:37:48PM -0500, Dave Brodin wrote: > > > > > I ran the following command: > > > > > > time /usr/local/bin/smtp-source -s 10 -l 10120 -m 500 -c \ > > > -f t...@bluemarble.net -t dbro...@bluemarble.net localhost:25 > > > > OK, this is smtp-source with 10 (modest) parallel sessions, > > 10KB (modest) messages, total 500 messages. This should typically > > accept mail at 100+ messages a second finishing in under 5 seconds. > > > > > And got the following output at the end: > > > > > > real0m58.261s > > > user0m0.055s > > > sys 0m0.126s > > For what it's worth, here is one data point for Postfix 2.8-20101210 > on FreeBSD 8.2-Beta1 i386 with 2 CPUs running as a VirtualBox guest, > with the smtp-source program in the VirtualBox guest. This delivers > mail to /dev/null, and ps(1) shows 10 smtpd processes. The top(1) > output spikes briefly. > > /usr/bin/time ./smtp-source -t dev-n...@localhost -s 10 -l 10120 -m 500 -c > 168.100.189.20:25 > 500 > 3.29 real 0.00 user 0.11 sys > > I don't have a lot of hardware lying around for bare metal testing > but I can do a temporary install on a 64-bit 2-CPU laptop computer. Second data point: the test takes a similar amount of time on a bare metal machine (Postfix 2.8-20101210, FreeBSD 8.2-Beta1 amd64, Core 2 Duo CPU). Both Postfix and FreeBSD were installed "out of the box" without any additional kernel tuning or Postfix tuning. I may be able to do some quad-core tests in a week or so, but I would be surprised if the result will radically change. Wietse
Re: Trouble getting TLS working
This is a connection from google: Dec 15 19:57:56 kahlo postfix/smtpd[11144]: connect from mail-gw0-f44.google.com[74.125.83.44] Dec 15 19:57:56 kahlo postfix/smtpd[11144]: NOQUEUE: reject: RCPT from mail-gw0-f44.google.com[74.125.83.44]: 550 5.1.1 : Recipient address rejected: User unknown in local recipient table; from= to= proto=ESMTP helo= Dec 15 19:57:56 kahlo postfix/smtpd[11144]: disconnect from mail-gw0-f44.google.com[74.125.83.44] The domain theo.to is listed in mydestination, but the name "rainexpected" is not found in /etc/passwd or in /etc/aliases. This is a connection from comcast: Dec 15 19:58:28 kahlo postfix/smtpd[11144]: connect from c-68-48-70-58.hsd1.dc.comcast.net[68.48.70.58] Dec 15 19:58:29 kahlo postfix/smtpd[11144]: NOQUEUE: reject: RCPT from c-68-48-70-58.hsd1.dc.comcast.net[68.48.70.58]: 550 5.1.1 : Recipient address rejected: User unknown in local recipient table; from= to= proto=ESMTP helo= Dec 15 19:58:33 kahlo postfix/smtpd[11144]: lost connection after RCPT from c-68-48-70-58.hsd1.dc.comcast.net[68.48.70.58] Dec 15 19:58:33 kahlo postfix/smtpd[11144]: disconnect from c-68-48-70-58.hsd1.dc.comcast.net[68.48.70.58] Again, the domain theo.to is listed in mydestination, but the name "rainexpected" is not found in /etc/passwd or in /etc/aliases. You also have a configuration error: Dec 15 19:57:51 kahlo postfix/trivial-rewrite[11148]: warning: do not list domain theo.to in BOTH mydestination and virtual_mailbox_domains Fix that. If you have the users in virtual_mailbox_maps, then don't list the domain in mydestination. Wietse Wietse
Re: statistics about use of webmail
On tor 16 dec 2010 12:06:18 CET, deconya wrote Im using Postfix + Dovecot + openldap + rouncube. If you need more info please comment me. grep 127.0.0.1 /var/log/maillog | grep 143 | sort -u | wc -l | mrtg.sh :-) maybe not perfect, but inspiration is free -- xpoint
Re: Trouble getting TLS working
On Thu, 16 Dec 2010 10:59:04 -0500 (EST) Wietse Venema wrote: > This is a connection from google: > > Dec 15 19:57:56 kahlo postfix/smtpd[11144]: connect from > mail-gw0-f44.google.com[74.125.83.44] Dec 15 19:57:56 kahlo > postfix/smtpd[11144]: NOQUEUE: reject: RCPT from > mail-gw0-f44.google.com[74.125.83.44]: 550 5.1.1 > : Recipient address rejected: User unknown in > local recipient table; > from= > to= proto=ESMTP helo= > Dec 15 19:57:56 kahlo postfix/smtpd[11144]: disconnect from > mail-gw0-f44.google.com[74.125.83.44] > > The domain theo.to is listed in mydestination, but the name > "rainexpected" is not found in /etc/passwd or in /etc/aliases. > > This is a connection from comcast: > > Dec 15 19:58:28 kahlo postfix/smtpd[11144]: connect from > c-68-48-70-58.hsd1.dc.comcast.net[68.48.70.58] Dec 15 19:58:29 kahlo > postfix/smtpd[11144]: NOQUEUE: reject: RCPT from > c-68-48-70-58.hsd1.dc.comcast.net[68.48.70.58]: 550 5.1.1 > : Recipient address rejected: User unknown in > local recipient table; from= > to= proto=ESMTP helo= Dec 15 > 19:58:33 kahlo postfix/smtpd[11144]: lost connection after RCPT from > c-68-48-70-58.hsd1.dc.comcast.net[68.48.70.58] Dec 15 19:58:33 kahlo > postfix/smtpd[11144]: disconnect from > c-68-48-70-58.hsd1.dc.comcast.net[68.48.70.58] > > Again, the domain theo.to is listed in mydestination, but the name > "rainexpected" is not found in /etc/passwd or in /etc/aliases. > > You also have a configuration error: > > Dec 15 19:57:51 kahlo postfix/trivial-rewrite[11148]: warning: do not > list domain theo.to in BOTH mydestination and virtual_mailbox_domains > > Fix that. If you have the users in virtual_mailbox_maps, then don't > list the domain in mydestination. > > Wietse > Wietse Thank you very much! Everything is working now!
Re: CC all messages relayed through postfix
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. Only two admins, the owner (my boss) and I have access to the mail storage. We want to bcc all mail RELAYED, not received, to a folder that is accessible by the other admins AND strip headers from the mail, other than the queue ID. The messages should ONLY be search-able by the queue id, not by wildcards and such searching by email addresses; this is wanted for the privacy and security. The headers as to the systems the mail went through and the message itself should remain intact but the "from" and "to" should be stripped; the head admins can look through the logs to see who sent and received it. -- Jerrale G. SC Senior Admin
Re: CC all messages relayed through postfix
On 12/16/2010 12:20 PM, Jerrale G wrote: 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. Only two admins, the owner (my boss) and I have access to the mail storage. We want to bcc all mail RELAYED, not received, to a folder that is accessible by the other admins AND strip headers from the mail, other than the queue ID. The messages should ONLY be search-able by the queue id, not by wildcards and such searching by email addresses; this is wanted for the privacy and security. The headers as to the systems the mail went through and the message itself should remain intact but the "from" and "to" should be stripped; the head admins can look through the logs to see who sent and received it. To be more simpler in explaining, no other admins but the two should be able to put the entire message back together without having access to all parts of the system. Jerrale G. SC Senior Admin
Re: selective behaviour for reject_sender_login_mismatch ?
Victor Duchovni wrote: > 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? Just a quick follow-up - I would have been glad to produce a patch for a check_sasluser_access, but I'm not sufficiently familiar with the postfix code. For my own needs, I have implemented a policy daemon (the coding of which I am far more familiar with). /Per Jessen, Zürich
How can content filter tell if upstream client authenticated?
How can a Postfix "content filter" tell whether the upstream client authenticated or not? I'm working on a content filter which should behave differently, depending on whether the upstream client authenticated to Postfix or not
Re: How can content filter tell if upstream client authenticated?
On Thu, Dec 16, 2010 at 10:16:08AM -0800, Jack Bates wrote: > How can a Postfix "content filter" tell whether the upstream client > authenticated or not? If the top-most Received header matches "with (SMTP|ESMTPS?A?)", the "ESMTPSA" and "ESMTPA" cases correspond to an authenticated client, with or without TLS. Adjust appropriately if the content filter is more than one hop away from the MSA. And don't discard that header. You can also arrange to record the SASL user name in the same header. http://www.postfix.org/postconf.5.html#smtpd_sasl_authenticated_header and if you like remove this in transit through the filter. -- Viktor.
Re: How can content filter tell if upstream client authenticated?
Jack Bates: > How can a Postfix "content filter" tell whether the upstream client > authenticated or not? > > I'm working on a content filter which should behave differently, > depending on whether the upstream client authenticated to Postfix or not Set "smtpd_sasl_authenticated_header = yes" if the client anthenticates with sasl (or with Postfix 2.5 and later, look for the "Received ... with ESMTPA or ESMTPSA ..." header). Set "smtpd_tls_received_header = yes" if the client authenticates with a TLS certificate. Wietse
Re: Load issues with Postfix on FreeBSD
Many thanks to Scott Lambert for what I believe to be the solution to my load problem. It was nsswitch.conf which still had all its default settings when I began this troubleshooting. I had changed all the entries from nis to files when he mentioned it a few days ago. But he then suggested changing the compat setting for group and passwd to files also. So it now looks like: group: files group_files: nis hosts: files dns networks: files passwd: compat passwd_files: nis shells: files services: files services_files: nis protocols: files rpc: files Here is the load testing result from before the change: [root] time /usr/local/bin/smtp-source -s 10 -l 10120 -m 500 -c -f t...@bluemarble.net -t dbro...@bluemarble.net localhost:25 500 real0m58.122s user0m0.029s sys 0m0.135s And after: [root] time /usr/local/bin/smtp-source -s 10 -l 10120 -m 500 -c -f t...@bluemarble.net -t dbro...@bluemarble.net localhost:25 500 real0m0.358s user0m0.063s sys 0m0.135s Can't wait to see how it handles under a real mail load once I can schedule the migration from the current server. Thanks again for all the help. Dave Brodin On 12/16/2010 10:46 AM, Wietse Venema wrote: Wietse Venema: Victor Duchovni: On Wed, Dec 15, 2010 at 01:37:48PM -0500, Dave Brodin wrote: I ran the following command: time /usr/local/bin/smtp-source -s 10 -l 10120 -m 500 -c \ -f t...@bluemarble.net -t dbro...@bluemarble.net localhost:25 OK, this is smtp-source with 10 (modest) parallel sessions, 10KB (modest) messages, total 500 messages. This should typically accept mail at 100+ messages a second finishing in under 5 seconds. And got the following output at the end: real0m58.261s user0m0.055s sys 0m0.126s For what it's worth, here is one data point for Postfix 2.8-20101210 on FreeBSD 8.2-Beta1 i386 with 2 CPUs running as a VirtualBox guest, with the smtp-source program in the VirtualBox guest. This delivers mail to /dev/null, and ps(1) shows 10 smtpd processes. The top(1) output spikes briefly. /usr/bin/time ./smtp-source -t dev-n...@localhost -s 10 -l 10120 -m 500 -c 168.100.189.20:25 500 3.29 real 0.00 user 0.11 sys I don't have a lot of hardware lying around for bare metal testing but I can do a temporary install on a 64-bit 2-CPU laptop computer. Second data point: the test takes a similar amount of time on a bare metal machine (Postfix 2.8-20101210, FreeBSD 8.2-Beta1 amd64, Core 2 Duo CPU). Both Postfix and FreeBSD were installed "out of the box" without any additional kernel tuning or Postfix tuning. I may be able to do some quad-core tests in a week or so, but I would be surprised if the result will radically change. Wietse -- Dave Brodin Network Operations Manager Smithville Digital This message may contain information that is confidential. If you are not an intended recipient, use and disclosure of this message are prohibited. If you received this transmission in error, please notify the sender by reply e-mail and delete the message and any attachments.
Re: Load issues with Postfix on FreeBSD
Dave Brodin: [ Charset ISO-8859-1 unsupported, converting... ] > Many thanks to Scott Lambert for what I believe to be the solution to my > load problem. It was nsswitch.conf which still had all its default > settings when I began this troubleshooting. I had changed all the > entries from nis to files when he mentioned it a few days ago. But he > then suggested changing the compat setting for group and passwd to files > also. > > So it now looks like: > > group: files > group_files: nis > hosts: files dns > networks: files > passwd: compat > passwd_files: nis > shells: files > services: files > services_files: nis > protocols: files > rpc: files OK, before less-informed people start to spread urban legends, I did all the measurements with the default nsswitch.conf file (see below) which contains the exact same entries that were making your system crawl. So, while Postfix is now performing better for you, I am less convinced that everything is kosher, unless someone can explain to why the default nsswitch.conf was no good for your particular system (or why it was burning up 98% CPU in kernel mode). Wietse group: compat group_compat: nis hosts: files dns networks: files passwd: compat passwd_compat: nis shells: files services: compat services_compat: nis protocols: files rpc: files
Re: Load issues with Postfix on FreeBSD
On 12/16/2010 3:00 PM, Wietse Venema wrote: Dave Brodin: [ Charset ISO-8859-1 unsupported, converting... ] Many thanks to Scott Lambert for what I believe to be the solution to my load problem. It was nsswitch.conf which still had all its default settings when I began this troubleshooting. I had changed all the entries from nis to files when he mentioned it a few days ago. But he then suggested changing the compat setting for group and passwd to files also. So it now looks like: group: files group_files: nis hosts: files dns networks: files passwd: compat passwd_files: nis shells: files services: files services_files: nis protocols: files rpc: files OK, before less-informed people start to spread urban legends, I did all the measurements with the default nsswitch.conf file (see below) which contains the exact same entries that were making your system crawl. So, while Postfix is now performing better for you, I am less convinced that everything is kosher, unless someone can explain to why the default nsswitch.conf was no good for your particular system (or why it was burning up 98% CPU in kernel mode). Wietse group: compat group_compat: nis hosts: files dns networks: files passwd: compat passwd_compat: nis shells: files services: compat services_compat: nis protocols: files rpc: files OK. I'm going to put nsswitch.conf back to the way it was, revert my postfix configuration back to an out of the box setup, and then see if the CPU is still overloaded. -- Dave Brodin Network Operations Manager Smithville Digital This message may contain information that is confidential. If you are not an intended recipient, use and disclosure of this message are prohibited. If you received this transmission in error, please notify the sender by reply e-mail and delete the message and any attachments.
Re: using yahoo smtp with several accounts
Noel Jones escribió: > On 12/15/2010 8:42 AM, Roger Durañona Vargas wrote: >> Alfonso Alejandro Reyes Jimenez escribió: >>> Hi, I'm not an expert on postfix but I think you have an issue with >>> your authentication. >>> >>> Are you sure you are not sending emails with the same username and >>> password as the other account ?? (the account that works?) or maybe >>> you are trying to send emails without authentication. >>> >>> I hope this information help you. >>> >> I have set up sasl and a saslpass file with the first account: >> smtp.correo.yahoo.esu...@yahoo.es:pass >> >> and then ran postmap on it. I added the second too but it doesnt solves >> the problem. According to what my friend told me, it is enough to auth a >> single account, and also I should have a certificate. >> > > > You certainly DO NOT need a certificate. > > You need to read and follow these directions: > http://www.postfix.org/SOHO_README.html#client_sasl_sender Seems that those directins dotn apply when we are talking about yahoo. I got the same result, any additional account gets the 553 error when sending. Made a quick test with mdaemon and the result is the same, but managed to make 2 accoutns work by rotating them as the account used to authenticate. -- Roger D. Vargas Using Gentoo Linux 2010 La unica forma de encontrar los limites de lo posible es yendo mas alla de ellos, hacia lo imposible
Re: Load issues with Postfix on FreeBSD
On Thu, Dec 16, 2010 at 03:00:39PM -0500, Wietse Venema wrote: > Dave Brodin: > > Many thanks to Scott Lambert for what I believe to be the solution > > to my load problem. It was nsswitch.conf which still had all its > > default settings when I began this troubleshooting. I had changed > > all the entries from nis to files when he mentioned it a few days > > ago. But he then suggested changing the compat setting for group > > and passwd to files also. > > > > So it now looks like: > > > > group: files > > group_files: nis > > hosts: files dns > > networks: files > > passwd: compat > > passwd_files: nis > > shells: files > > services: files > > services_files: nis > > protocols: files > > rpc: files > > OK, before less-informed people start to spread urban legends, I did > all the measurements with the default nsswitch.conf file (see below) > which contains the exact same entries that were making your system > crawl. > > So, while Postfix is now performing better for you, I am less > convinced that everything is kosher, unless someone can explain to why > the default nsswitch.conf was no good for your particular system (or > why it was burning up 98% CPU in kernel mode). This is not postfix specific. Just in case anyone was inferring that. It has to do with the number of entries in the password file. I do not remember the details for why, but with thousands of users in the password file anything that maps usernames to uids gets slow with passwd and group set to compat. The first time I saw the problem was with ls -l in /home on a machine with thousands of users. It took minutes. ls -ln completed as quickly as the pty could display the output. I do not have that issue on my cyrus-imapd box which has 20 users in the password file, but eight thousand e-mail accounts/mailboxes in Cyrus with Cyrus SASL and Postfix using MySQL storage for the mailbox lookups/authentication data. Running ncsd may also mitigate the issue. I have not tried that. I was happy to eliminate the latency without running an additional daemon. I do not understand why the default "compat" option, which seems to be designed to mimic pre-nsswitch behaviour, is slower than the "files" option. -- Scott LambertKC5MLE Unix SysAdmin lamb...@lambertfam.org
PATCH: using yahoo smtp with several accounts
Noel Jones:
> You need to read and follow these directions:
> http://www.postfix.org/SOHO_README.html#client_sasl_sender
Roger Dura?ona Vargas:
> Seems that those directins dotn apply when we are talking about yahoo. I
> got the same result, any additional account gets the 553 error when
> sending. Made a quick test with mdaemon and the result is the same, but
> managed to make 2 accoutns work by rotating them as the account used to
> authenticate.
I think I found the bug. When Postfix sends SMTP mail it tries NOT
to reuse a connection when sender-dependent SASL authentication is
turned on.
Unfortunately the test is wrong, and thus it is possible that
Postfix sends mail for sender X over an SMTP connection that was
used to send mail for sender Y (and thus, over a connection that
was logged into YAHOO as user Y).
You can configure Postfix not to reuse SMTP connections when sending
mail:
/etc/postfix/main.cf
smtp_connection_cache_on_demand = no
Or you can use the patch below.
Wietse
*** ./src/smtp/smtp_connect.c- Fri Nov 27 10:52:10 2009
--- ./src/smtp/smtp_connect.c Thu Dec 16 16:57:07 2010
***
*** 461,467
* connection, and we must not send mail that requires authentication
* over a connection that wasn't authenticated.
*/
! if (var_smtp_sender_auth)
return;
if (smtp_cache_dest && string_list_match(smtp_cache_dest, dest)) {
--- 461,467
* connection, and we must not send mail that requires authentication
* over a connection that wasn't authenticated.
*/
! if (*var_smtp_sender_auth)
return;
if (smtp_cache_dest && string_list_match(smtp_cache_dest, dest)) {
Re: Load issues with Postfix on FreeBSD
Scott Lambert: > > OK, before less-informed people start to spread urban legends, I did > > all the measurements with the default nsswitch.conf file (see below) > > which contains the exact same entries that were making your system > > crawl. > > > > So, while Postfix is now performing better for you, I am less > > convinced that everything is kosher, unless someone can explain to why > > the default nsswitch.conf was no good for your particular system (or > > why it was burning up 98% CPU in kernel mode). > > This is not postfix specific. Just in case anyone was inferring > that. > > It has to do with the number of entries in the password file. I > do not remember the details for why, but with thousands of users > in the password file anything that maps usernames to uids gets slow > with passwd and group set to compat. The first time I saw the > problem was with ls -l in /home on a machine with thousands of > users. It took minutes. ls -ln completed as quickly as the pty > could display the output. Thanks for the backgrouns. Could you please file a bug report. Originally, 4.4BSD uses a hashed password file, so there is no excuse why lookups from file should be slow, especially with the default nsswitch file which is what everyone ends up using. Wietse > I do not have that issue on my cyrus-imapd box which has 20 users > in the password file, but eight thousand e-mail accounts/mailboxes > in Cyrus with Cyrus SASL and Postfix using MySQL storage for the > mailbox lookups/authentication data. > > Running ncsd may also mitigate the issue. I have not tried that. > I was happy to eliminate the latency without running an additional > daemon. > > I do not understand why the default "compat" option, which seems > to be designed to mimic pre-nsswitch behaviour, is slower than the > "files" option. > > -- > Scott LambertKC5MLE Unix SysAdmin > lamb...@lambertfam.org > >
Re: PATCH: using yahoo smtp with several accounts
Wietse Venema: > Noel Jones: > > You need to read and follow these directions: > > http://www.postfix.org/SOHO_README.html#client_sasl_sender > > Roger Dura_ona Vargas: > > Seems that those directins dotn apply when we are talking about yahoo. I > > got the same result, any additional account gets the 553 error when > > sending. Made a quick test with mdaemon and the result is the same, but > > managed to make 2 accoutns work by rotating them as the account used to > > authenticate. > > I think I found the bug. When Postfix sends SMTP mail it tries NOT > to reuse a connection when sender-dependent SASL authentication is > turned on. This is a mis-diagnosis. The variable in question is a boolean type, and there is no way that Postfix can resuse an SMTP connection while sender-dependent SASL authentication is turned on. Wietse
.Forward file piping forwarded mail (abort sendmail)
Hi
Anybody have idea about| if [ grep '[][{!-]Spam[][?}].*'| nawk '{print
$1}' == 1 ] ...command works in .forward file ?
thanks.
/s
selcukyazar wrote:
>
> Hi
>
> my .forward manupulation works.
>
> "| sed -e 's/Subject:/Subject:FW: /g' -e '/'Received:\.\*'/{N;d}'|
> /usr/sbin/sendmail -i mail_ad...@hotmail.com"
> -considering bounce loops-
> ok, also i wantto use command like this;
>
> if [ `expr match "$str" "[][{!-]Spam[][?}].*"` != "0" ]; then abort
> forwarding anyway fi
>
> is it possible and what can be $str(i think its mail source)
>
>
> thanks in advance.
>
> selcuk
>
>
--
View this message in context:
http://old.nabble.com/.Forward-file-piping-forwarded-mail-%28abort-sendmail%29-tp30470508p30476841.html
Sent from the Postfix mailing list archive at Nabble.com.
Re: .Forward file piping forwarded mail (abort sendmail)
2010/12/17 selcukyazar :
>
>
> Hi
>
> Anybody have idea about | if [ grep '[][{!-]Spam[][?}].*'| nawk '{print
> $1}' == 1 ] ... command works in .forward file ?
try procmail or maildrop ?
--
Eero
Re: using yahoo smtp with several accounts
On Wed, Dec 15, 2010 at 02:42:00PM +, Roger Dura?ona Vargas wrote: > I have set up sasl and a saslpass file with the first account: > smtp.correo.yahoo.es u...@yahoo.es:pass This is wrong. The lookup key needs to be the sender address, and you need to enable sender-specific SASL lookups, see the docs. -- Viktor.
Re: Load issues with Postfix on FreeBSD
On Thu, 2010-12-16 at 17:05:13 -0500, Wietse Venema wrote: > Scott Lambert: > > > OK, before less-informed people start to spread urban legends, I did > > > all the measurements with the default nsswitch.conf file (see below) > > > which contains the exact same entries that were making your system > > > crawl. > > > > > > So, while Postfix is now performing better for you, I am less > > > convinced that everything is kosher, unless someone can explain to why > > > the default nsswitch.conf was no good for your particular system (or > > > why it was burning up 98% CPU in kernel mode). > > > > This is not postfix specific. Just in case anyone was inferring > > that. > > > > It has to do with the number of entries in the password file. I > > do not remember the details for why, but with thousands of users > > in the password file anything that maps usernames to uids gets slow > > with passwd and group set to compat. The first time I saw the > > problem was with ls -l in /home on a machine with thousands of > > users. It took minutes. ls -ln completed as quickly as the pty > > could display the output. > > Thanks for the backgrouns. > > Could you please file a bug report. Originally, 4.4BSD uses a hashed > password file, so there is no excuse why lookups from file should > be slow, especially with the default nsswitch file which is what > everyone ends up using. A bug report[1] about a similar problem was filed several years ago. Remarkably, it remains open. I hope to convince someone to take a look soon. [1] http://www.freebsd.org/cgi/query-pr.cgi?pr=75855 -- Sahil Tandon
Re: Load issues with Postfix on FreeBSD
On Thu, Dec 16, 2010 at 05:05:13PM -0500, Wietse Venema wrote: > Scott Lambert: > > > OK, before less-informed people start to spread urban legends, I did > > > all the measurements with the default nsswitch.conf file (see below) > > > which contains the exact same entries that were making your system > > > crawl. > > > > > > So, while Postfix is now performing better for you, I am less > > > convinced that everything is kosher, unless someone can explain to why > > > the default nsswitch.conf was no good for your particular system (or > > > why it was burning up 98% CPU in kernel mode). > > > > This is not postfix specific. Just in case anyone was inferring > > that. > > > > It has to do with the number of entries in the password file. I > > do not remember the details for why, but with thousands of users > > in the password file anything that maps usernames to uids gets slow > > with passwd and group set to compat. The first time I saw the > > problem was with ls -l in /home on a machine with thousands of > > users. It took minutes. ls -ln completed as quickly as the pty > > could display the output. > > Thanks for the backgrouns. > > Could you please file a bug report. Originally, 4.4BSD uses a hashed > password file, so there is no excuse why lookups from file should > be slow, especially with the default nsswitch file which is what > everyone ends up using. > > Wietse Apparantly, I exaggerated the slowness of the ls -l. I finally found my thread from 2007 when I first found and asked about this. http://unix.derkeiler.com/Mailing-Lists/FreeBSD/stable/2007-04/msg00193.html I'll go ahead and file a PR. There don't seem to be too many people complaining about this. -- Scott LambertKC5MLE Unix SysAdmin lamb...@lambertfam.org
Alias problem
Hi, I have a problem with aliases, and would like to make it work. I have the following situation I have two servers one postfix v 2.0.18 and on the other (new one) v 2.6.5. The problem is that I have migrated some users to the new server and set up transport maps for them on the old server. The users are also referred to in /etc/aliases file. Still somehow these specific users do not receive mail when sent to the alias they are in. And also there is no message in the logs that would explain the situation. aliases are grouped: aliasmaster: alias1, alias2, alias3, ... alias1: user1, user2, user3 alias2: user4, user5, user6 ... So the mail is allways sent to aliasmas...@domain.tld I have also tried adding usern...@newmailserverfqdn to the aliases file, but it seems to behave exactly the same as before - the users are just being ignored. I did run postalias (many times...). Can someone enlighten me on what I am doing wrong and how to fix it. I would really appreciate your help since right now I have run out of ideas. Regards, Bostjan
