Re: postfix stats
On 01/05/2015 17:45, Benning, Markus wrote: Hi, if you are willed to test my pflogsumm fork and to provide some sample loglines i'll implement postscreen statistics. You can find the project at Github: https://github.com/benningm/saftpresse I modularized the pflogsumm code into seperate plugins: https://github.com/benningm/saftpresse/tree/master/lib/Log/Saftpresse/Plugin Also Input and Outputs. There are 2 commands. The command saftpresse will be a new interface to the code which is configurable by configuration file. It is still work in progress. The command saftsumm tries to resemble the pflogsumm commandline interface. Additional features already in it are TLS and GeoIP statistics, and different outputs. Currently pflogsumm, HTML, JSON and perl Dump. My goal for saftpresse is to use it also for structured logging and to implement more than just postfix logging. Can you provide more information how to install? The following command do nothing: #./saftsumm -d yesterday /var/log/maillog What I do on Centos 6.6: put the lib/Log to /usr/share/perl5/ The test.pl says: Parameter module is not defined for Input FileTail! at /usr/share/perl5/Log/Saftpresse/Slurp.pm line 62. Thanks, -- Levi
RE: Postfix forward mail to other server but leaving a copy...
Oops, I missed that Alex had already posted this suggestion. Sorry! > Am 30.04.2015 um 13:43 schrieb gilbertoferreira: > > Thanks for your answer, but I need this only for a few accounts... > > I thing use procmail or .forward rules... > > Have a look at recipient_bcc_maps: > http://www.postfix.org/postconf.5.html#recipient_bcc_maps > > -- > Alex JOST
Re: maxproc in master.cf
On 05/05/15 12:24, Viktor Dukhovni wrote: On Tue, May 05, 2015 at 12:12:10PM +0530, dE wrote: "The maximum number of processes that may execute this service simultaneously." The maximum number of daemon processes master(8) will fork/exec to process incoming requests for the service. But a single spawned daemon is supposed to listen to the unix/inet socket or fifo; if multiple daemons listen on the single port, how is the concurrency problem handled?
Re: maxproc in master.cf
On Tue, May 05, 2015 at 09:17:06PM +0530, dE wrote: > if multiple daemons listen on the single port, how is the concurrency > problem handled? TL;DR: Correctly. In detail: Multiple processes indeed share the acceptor socket, but only one (otherwise) idle process at a time is monitoring it for new connections. The rest (of the idle processes) are blocked on a file lock, which is released by the lock holder once it accepts a connection to process (and is no longer idle). -- Viktor.
Re: Stan Hoeppner's fqrdns.pcre file?
On 27/04/15 6:53 am, Bill Cole wrote: On 26 Apr 2015, at 17:21, Steve Jenkins wrote: On Sun, Apr 26, 2015 at 1:11 PM, E.B. wrote: HasStan stopped hosting/maintaining it? Yes. :( Like I said, it appears Stan has disappeared. His last archived post was to the XFS list in January. I can't find him on social media, and any Google searches for him produce his hardwarefreak.com site... which is now being squatted. If you make just the right search you can find a Stanley Hoeppner being held in the L. A. County jail on a stalking charge since Feb. 13, but that seems very unlikely to be the Stan Hoeppner of Tarkio MO who owned hardwarefreak.com. There was a missing persons report on a Stanley D Hoeppner. This name no longer appears on the active missing persons list. Hope he is ok. FYI: http://i.imgur.com/3oiR3ID.png Also, It seems that his server is up and running. there is a single jpg file with you point the browser to his server IP. The fqrdns.pcre file is at http://65.41.216.221/fqrdns.pcre -Vijay
"smtp_sasl_auth_enable = yes" for specific peers only?
Hi, I am having trouble sending mail to a specific smtp host, which is configured for sasl authentication on port 25. I have configured Postfix to send smtp mail from a small number of local domains to the recipient domain's mail exchanger, and to send mail from non local domains such as gmx.de and gmail.com via the appropriate relays using sender_dependent lists. All worked fine until today. The peer that causes trouble is using sasl authentication on port 25, to allow authenticated users sending mail via smtp instead of submission. However, if I try to send mail from an address within one of my local domains to this peer, it fails: May 5 21:46:08 prokyon postfix/smtp[8971]: 983C83CA2: to=, relay=mail.anonymized.de[217.111.111.111]:25, delay=368, delays=363/1.9/3.1/0, dsn=4.7.8, status=deferred (SASL authentication failed; server mail.anonymized.de[217.111.111.111] said: 535 5.7.8 Error: authentication failed: authentication failure) This is what I get when probing the peer: root@prokyon:/etc/postfix# telnet mail.anonymized.de 25 Trying 217.111.111.111... Connected to mail.anonymized.de. Escape character is '^]'. 220 mail.ktit.de ESMTP Postfix EHLO mydomain.de 250-mail.anonymized.de 250-PIPELINING 250-SIZE 250-ETRN 250-STARTTLS 250-AUTH LOGIN DIGEST-MD5 CRAM-MD5 PLAIN 250-AUTH=LOGIN DIGEST-MD5 CRAM-MD5 PLAIN 250-ENHANCEDSTATUSCODES 250-8BITMIME 250 DSN quit 221 2.0.0 Bye Connection closed by foreign host. So, my own Postfix tries to authenticate to this server, but of course fails as it does not have any credentials. I see that this seems to be caused by the smtp_sasl_auth_enable = yes flag set in main.cf, which I need because without this, Postfix will never try to authenticate to the sender_dependent relays, e.g. for gmail.com. I don't know what to do about this, is there a way to tell Postfix to only authenticate to those relays defined in sender_dependent, or only when connecting to the submission port? Or can this be a misconfiguration at the peer's side? Thank you for help, Robert signature.asc Description: This is a digitally signed message part
Re: "smtp_sasl_auth_enable = yes" for specific peers only?
You can suppress the remote SMTP server's AUTH announcement with smtp_discard_ehlo_keyword_maps. Wietse
Re: "smtp_sasl_auth_enable = yes" for specific peers only?
Hi Wietse, thanks, I am using Postfix 2.11, and I assume the parameter is smtp_discard_ehlo_keyword_address_maps, right? I tried that, and it worked for the specific peer, thanks again. But I wonder why I never received any bounced error message. I've seen Postfix retrying several times in the log, until the message vanished from the queue. So, if this happens again with any other peer, I don't have a chance to detect this kind of failure but by checking the logs? Regards, Robert Am Dienstag, den 05.05.2015, 16:46 -0400 schrieb Wietse Venema: > You can suppress the remote SMTP server's AUTH announcement with > smtp_discard_ehlo_keyword_maps. > > Wietse -- Robert Senger PGP/GPG Public Key ID: 24E78B5E signature.asc Description: This is a digitally signed message part
Re: "smtp_sasl_auth_enable = yes" for specific peers only?
On Tue, May 05, 2015 at 10:22:42PM +0200, Robert Senger wrote: > I am having trouble sending mail to a specific smtp host, which is > configured for sasl authentication on port 25. This should have no impact on your machine, unless you also configure smtp_sasl_password_maps non-empty, and configure a table entry that matches the nexthop domain (the smtp host in question). > I have configured Postfix to send smtp mail from a small number of local > domains to the recipient domain's mail exchanger, and to send mail from > non local domains such as gmx.de and gmail.com via the appropriate > relays using sender_dependent lists. All worked fine until today. If you do configure sender-dependent SASL authentication, then you MUST either ensure that all outbound mail from the sender in question goes through the expected relay (for which the sender has credentials), via sender_dependent_relayhost_maps, or via a different transport via sender_dependent_default_transport_maps, so that you never connect to some other relay expecting to authenticate because you've configured a sender-specific SASL password. > The peer that causes trouble is using sasl authentication on port 25, to > allow authenticated users sending mail via smtp instead of submission. The trouble is not the peer. It is your server's misconfiguration. Postfix happily ignores remote "AUTH" by default, unless you've configured a password for the destination or the sender. > So, my own Postfix tries to authenticate to this server, but of course > fails as it does not have any credentials. It does, for the sender. > I see that this seems to be caused by the smtp_sasl_auth_enable = yes > flag set in main.cf, which I need because without this, Postfix will > never try to authenticate to the sender_dependent relays, e.g. for > gmail.com. No, that's not the reason. Even with that on, authentication only happens to destinations (or for senders) for which you've set a password. > I don't know what to do about this, is there a way to tell Postfix to > only authenticate to those relays defined in sender_dependent, or only > when connecting to the submission port? > > Or can this be a misconfiguration at the peer's side? Misconfiguration on your side. -- Viktor.
Re: maxproc in master.cf
On 05/05/15 21:30, Viktor Dukhovni wrote: On Tue, May 05, 2015 at 09:17:06PM +0530, dE wrote: if multiple daemons listen on the single port, how is the concurrency problem handled? TL;DR: Correctly. In detail: Multiple processes indeed share the acceptor socket, but only one (otherwise) idle process at a time is monitoring it for new connections. The rest (of the idle processes) are blocked on a file lock, which is released by the lock holder once it accepts a connection to process (and is no longer idle). Thanks for sharing the detail! I would like this get documented.
Re: maxproc in master.cf
On Wed, May 06, 2015 at 07:10:55AM +0530, dE wrote: > On 05/05/15 21:30, Viktor Dukhovni wrote: > >On Tue, May 05, 2015 at 09:17:06PM +0530, dE wrote: > > > >>if multiple daemons listen on the single port, how is the concurrency > >>problem handled? > >TL;DR: Correctly. > > > >In detail: Multiple processes indeed share the acceptor socket, > >but only one (otherwise) idle process at a time is monitoring it > >for new connections. The rest (of the idle processes) are blocked > >on a file lock, which is released by the lock holder once it accepts > >a connection to process (and is no longer idle). > > > > Thanks for sharing the detail! I would like this get documented. This is internal implementation detail, not a public interface. The source is available for those who want details. All that master.cf promises is a bound on the number of processes running for each service, and that is actually clear from master(5), unless you're working too hard trying to guess the implementation details (wrong), and get yourself confused. -- Viktor.
