Re: NOW: permit action logging -- WAS: permit_dnswl_client logging
On 2/26/2012 4:55 PM, Wietse Venema wrote: > Stan Hoeppner: >> On 2/26/2012 2:15 PM, Wietse Venema wrote: >>> Stan Hoeppner: I can't seem to find any logging of permit_dnswl_client actions. Maybe I just don't know what to grep for. I would like to be able to track such data. >>> >>> Are there any "permit" features that log their decision? >> >> No. > > Reflecting Postfix origins that go back to days that most email was > not spam. > >>> Hard-coding it "on" only for some would make little sense. >> >> I agree. > > We have a bunch of permit actions: > > all-numerical (in access maps only) > ok (in access maps only) > permit > permit_auth_destination > permit_dnswl_client > permit_inet_interfaces > permit_mx_backup > permit_mynetworks > permit_rhswl_client > permit_sasl_authenticated > permit_tls_all_clientcerts > permit_tls_clientcerts > > Retrofitting is not hard if we do it right: in all access control > code that decides to permit something, replace this: > > return (SMTPD_CHECK_OK); > > with > > return (smtpd_check_permit(state, permit_action_name, > reply_class, reply_name, > format_string, arguments...)); > > If the permit_action_name appears in a configurable list of permit > action names, smtpd_check_permit() would log that the named permit > action fired, along with the values of: > > - reply_class (what kind of thing was permitted: client, helo, > sender, recipient, data, or end-of-data), > > - reply_name (the actual value of the thing that was permitted: a > client name[address], helo argument, etc.), > > - format_string+arguments with free text for additional context > (for example "whitelisted by name-of-dnsbl"). > > - and maybe also the client=xxx, helo=yyy, from=aaa, to=bbb > (this information is conveyed with the state argument). > > This would introduce one parameter with the names of the permit > actions that need to be logged, one hash table that is indexed with > the permit action name, and one function that searches this table > to find out if the extra logging is needed. That looks great Wietse. I know I would have in the past, and will in the future, find such permit logging very helpful. But I don't recall such a request from others. I'd rather not be the instigator of you wasting any development time on this if few others would want/use this capability. A show of hands or something would be nice--we have 2 so far. Thanks for taking the time to analyze my feature request and consider it for possible implementation Wietse. -- Stan
Re: permit_dnswl_client logging
On 2/27/2012 1:12 AM, Stan Hoeppner wrote: > On 2/26/2012 4:50 PM, /dev/rob0 wrote: > >> A "warn_if_permit" similar to "warn_if_reject" might make more sense >> and be more generic. I agree with your reasoning that the feature >> would be useful. >> >> "warn_if_reject" negates the following restriction, and likewise >> should "warn_if_permit". To actually use it as Stan describes, it >> would be: >> >> smtpd_mumble_restrictions = [ ... ] >> warn_if_permit permit_dnswl_client list.dnswl.org >> permit_dnswl_client list.dnswl.org >> [ ... ] > > I should have thought of that. Much better idea. And I should have thought more about this before replying. Would this disable the permit action? We certainly don't want to disable the permit action. I think I prefer Wietse's implementation idea. -- Stan
Re: postfix mysql lookup table has some kind of caching?
I dont think that the problem cames from transport map 1-element caching, because the destination is variable, we have millions of email addresses. I made some tests with mysql general logging enabled and i found that when mysql lookup table checks a transport for a destination it does a lookup for em...@domain.tld domain.tld .tld but the lookup for * is done just once, but for the rest it does all the time. This is how it was designed to be the * lookup? > What means this 1-element cache? it caches the last lookup? > Right. The cache is not specific to mysql, but is a feature of the trivial-rewrite transport lookup. This is only likely to be noticed when you use mysql-based transport_maps and a high percentage of the queue is for a single destination. This is not configurable. The workaround is to use a hash: or cdb: table, which triggers a restart of trivial-rewrite upon changes -- but note that frequent restarts of trivial-rewrite may be bad for performance.
queue file write error
Hello list, I received a message from my mail-daemon: From: Mail Delivery System To: Postmaster Subject: Postfix SMTP server: errors from ahost Transcript of session follows. Out: 220 myserver.example.com ESMTP Postfix In: EHLO ahost.example.com ... In: DATA Out: 354 End data with . Out: 451 4.3.0 Error: queue file write error In: QUIT Out: 221 2.0.0 Bye I investigated the problem and found out that my content filter caused the problem. The content filter, which is running as a proxy, took longer than $smtpd_proxy_timeout to process the message. After finishing the message the content filter submitted it back to postfix which finally delivered it. What makes me wonder is, that I can't find a hint about the 'queue file write error' in the logfile. From the log it looks as if there wasn't any problem with the message a all. Is that the intended behavior or are there some missing log lines? mail.log: postfix/smtpd[9540]: 87ED8DBA1B: client=ahost[A.B.C.D] postfix/cleanup[10812]: 87ED8DBA1B: message-id= postfix/qmgr[5468]: 87ED8DBA1B: from=, size=1145299, nrcpt=1 (queue active) postfix/smtp[10059]: 87ED8DBA1B: to=, relay=example.com[X.Y.Z.Z]:25, delay=0.56, delays=0.11/0/0.12/0.32, dsn=2.0.0, status=sent (250 Ok: queued as C8428C4C002) postfix/qmgr[5468]: 87ED8DBA1B: removed Thanks for your help. Stefan
Re: queue file write error
Stefan Jakobs: > What makes me wonder is, that I can't find a hint about the 'queue file write > error' in the logfile. From the log it looks as if there wasn't any problem > with the message a all. Is that the intended behavior or are there some > missing log lines? Postfix logs a timeout error as: warning: timeout talking to proxy Postfix logs a crashed proxy as: warning: lost connection with proxy If you don't see any warnings in your maillog file, then you are looking in the wrong file. Some systems separate the normal logging from the error logging, making trouble shooting more difficult. Wietse
Re: AW: forcing MX lookups
On 21/02/2012 19:26, Wietse Venema wrote: Ed W: As the OP suggested, a desirable solution would be for the MTA to only check the various maps to decide a domain is local *after* having done a DNS check to see if the MX record points "to this machine". ie the end goal is if the MX record points to some other machine, then we deliver to that machine, even if it's listed in our maps as being local... You can use transport_maps=tcp:host:port etc. to ask an external program for the MX lookup, and to have that external program decide if it should reply with a local mail delivery transport if the MX record points to your machine. This will drop your mail delivery performance quite a lot, as there is only one queue manager, and each mail delivery request will be waiting for the previous transport map lookup to complete. A better alternative may be check_recipient_mx_access at RCPT TO time. smtpd_recipient_restrictions = # This example assumes that we are not providing mail relay service # or mail submission service. ... reject_unauth_destination check_recipient_mx_access cidr:/etc/postfix/mxnetworks ... /etc/postfix/mxnetworks: # Assuming this is your network with MX servers. 1.2.3.4/24 dunno # If the MX did not match, reject the request. 0.0.0.0/0 reject This rejects mail when a recipient domain is "claimed" by one of your customers, but the MX host for the domain is not local. This is better than doing it at queue manager time, because multiple smtpd processes can do these MX lookups in parallel. Wietse Thanks this seems like the better solution. It would seem that an incremental tweak could be to combine both solutions, rather than reject, redirect to some transport map which forwards to some instance without local maps - this would cause the mail to be forwarded to the MX destination as defined by DNS. (Why: Most users should be fine with "reject", but for my requirements it's proved better to bounce invalid emails from *authorised users* vs rejecting at submission time. Mac Mail for example doesn't seem to correctly show reject error messages. Also we have users behind VERY slow dialup connections and bouncing works better for their submission process also.) Thanks for the solution! Ed W
Re: permit_dnswl_client logging
On 2/27/2012 2:15 AM, Stan Hoeppner wrote: > On 2/27/2012 1:12 AM, Stan Hoeppner wrote: >> On 2/26/2012 4:50 PM, /dev/rob0 wrote: >> >>> A "warn_if_permit" similar to "warn_if_reject" might make more sense >>> and be more generic. I agree with your reasoning that the feature >>> would be useful. >>> >>> "warn_if_reject" negates the following restriction, and likewise >>> should "warn_if_permit". To actually use it as Stan describes, it >>> would be: >>> >>> smtpd_mumble_restrictions = [ ... ] >>> warn_if_permit permit_dnswl_client list.dnswl.org >>> permit_dnswl_client list.dnswl.org >>> [ ... ] >> >> I should have thought of that. Much better idea. > > And I should have thought more about this before replying. Would this > disable the permit action? We certainly don't want to disable the > permit action. No, of course not. You perform the restriction twice; the warn_if_ is log-only, the second is live. You can do this now with warn_if_reject reject_rbl_client list.dnswl.org to log the hit. > > I think I prefer Wietse's implementation idea. > Yes, very useful general solution. I would use it. -- Noel Jones
Re: queue file write error (solved)
Am Montag, 27. Februar 2012, 13:03:46 schrieb Wietse Venema: > Stefan Jakobs: > > What makes me wonder is, that I can't find a hint about the 'queue file > > write error' in the logfile. From the log it looks as if there wasn't any > > problem with the message a all. Is that the intended behavior or are > > there some missing log lines? > > Postfix logs a timeout error as: > > warning: timeout talking to proxy > > Postfix logs a crashed proxy as: > > warning: lost connection with proxy > > If you don't see any warnings in your maillog file, then you are > looking in the wrong file. Some systems separate the normal logging > from the error logging, making trouble shooting more difficult. OK, I got it. I hadn't found the log lines, because they were not associated with the queue ID and they were logged a couple of seconds before Postfix had logged the reception of the message with its queue ID. Thanks for the clarification. > Wietse Regards Stefan
Protectin email distribution lists
Hi , Can we allow for one mail to send email our internal distribution list ? I mean, in the insider file, can we wrtite down an e-mail address rather than domain name. thanks in advance. -- Selçuk YAZAR
Re: permit_dnswl_client logging
Noel Jones: > No, of course not. You perform the restriction twice; the warn_if_ > is log-only, the second is live. You can do this now with > warn_if_reject reject_rbl_client list.dnswl.org to log the hit. > > > I think I prefer Wietse's implementation idea. > > Yes, very useful general solution. I would use it. In summary, there are two orthogonal features that should not be mixed up: - routine logging, which currently does not exist for permit actions. This requires one-time infrastructure code for "permit" logging, and calls to that infrastructure from a half-dozen strategic places (number of calls proportional to number of features). - warn-if logging, which one uses to test a feature before deployment. This takes a few lines of one-time infrastructure code. I have invested 2 hours to determine in detail what changes are needed to implement routine logging for permit actions, mostly in the part that is proportional to the number of features. Implementing routine permit logging would take a similar amount, and testing another couple hours. warn-if-permit logging is something that could be added later, simply by cloning a few lines of code from warn-if-reject. Wietse
Re: postfix mysql lookup table has some kind of caching?
B?ny?sz Botond: > I dont think that the problem cames from transport map 1-element > caching, because the destination is variable, we have millions of > email addresses. The trivial-rewrite server has a 1-element cache for the wild-card lookup result, and the trivial-rewrite client has a 1-element cache for repeated lookups. It is not a major effort to give those cache entries a finite time-to-live but this needs a better justification that what appears to be an attempt to circumvent Yahoo rate limits. Wietse
Re: Protectin email distribution lists
On Mon, Feb 27, 2012 at 03:33:48PM +0200, Selcuk Yazar wrote: > Can we allow for one mail to send email our internal > distribution list ? http://www.postfix.org/RESTRICTION_CLASS_README.html#internal > I mean, in the insider file, can we wrtite down an e-mail > address rather than domain name. check_recipient_access and check_sender_access lookups check individual addresses before domains. See the section "EMAIL ADDRESS PATTERNS" in: http://www.postfix.org/access.5.html -- http://rob0.nodns4.us/ -- system administration and consulting Offlist GMX mail is seen only if "/dev/rob0" is in the Subject:
Domain keys for postfix mail server
I installed and configured email server with postfix +dovecot and with virtual users and virtual domain. And now I want to setup a domain keys for my email server. Can I use opendkim ? And if have other solutions, please help me or provide that solution. Thank all.
Re: Domain keys for postfix mail server
On 2/27/2012 12:41 PM, KingT wrote: > I installed and configured email server with postfix +dovecot and > with virtual users and virtual domain. > > > > And now I want to setup a domain keys for my email server. > > > > Can I use opendkim ? OpenDKIM works great with postfix. For best results use the latest postfix patchlevel in whichever stable branch you're using, eg. 2.9.1, 2.8.8, 2.7.7, or 2.6.14 -- Noel Jones
RE: Domain keys for postfix mail server
Thanks your reply Noel Jones , I am finding a some document to config opendkim work with postfix, have you document or tutorial ? -Original Message- From: owner-postfix-us...@postfix.org [mailto:owner-postfix-us...@postfix.org] On Behalf Of Noel Jones Sent: Tuesday, February 28, 2012 1:51 AM To: postfix-users@postfix.org Subject: Re: Domain keys for postfix mail server On 2/27/2012 12:41 PM, KingT wrote: > I installed and configured email server with postfix +dovecot and > with virtual users and virtual domain. > > > > And now I want to setup a domain keys for my email server. > > > > Can I use opendkim ? OpenDKIM works great with postfix. For best results use the latest postfix patchlevel in whichever stable branch you're using, eg. 2.9.1, 2.8.8, 2.7.7, or 2.6.14 -- Noel Jones
RE: Domain keys for postfix mail server
> -Original Message- > From: owner-postfix-us...@postfix.org > [mailto:owner-postfix-us...@postfix.org] On Behalf Of KingT > Sent: Monday, February 27, 2012 7:29 PM > To: 'postfix users' > Cc: 'Noel Jones' > Subject: RE: Domain keys for postfix mail server > > Thanks your reply Noel Jones , > > I am finding a some document to config opendkim work with postfix, have > you document or tutorial ? A simple Google search reveals: http://www.elandsys.com/resources/mail/dkim/opendkim.html http://agiletesting.blogspot.com/2010/03/dkim-setup-with-postfix-and-opendkim.html http://stevejenkins.com/blog/2010/09/how-to-get-dkim-domainkeys-identified-mail-working-on-centos-5-5-and-postfix-using-opendkim/
sender_canonical_maps and from=<> address
Hi, I am trying to change the envelope sender appearing in Non Delivery Reports as from=<> using sender_canonical_maps hash file /etc/postfix/sender_canonical * *A7B2219E26: from=<>, size=86475, nrcpt=1 (queue active) [root@host log]# cat /etc/postfix/sender_canonical <> mail.ad...@example.com santosh.malav...@example.commail.ad...@example.com when i querry the key using postmap ( postmap -q "<>" hash: /etc/postfix/sender_canonical ) it gives me proper output. However, when the message is relayed, it does not change the from address. When I tried it in /etc/postfix/sender_access file, it allows relaying. ( smtp_null_access_lookup_key is default - when i trie) Regards, Santosh Malavade
