Postfix SASL auth - client alway sent e-mail even password change until I run again client app
Hi. I configured client auth for sending emails. Everythings work fine but when I change password for user I still can send email from outlook or thunderbird with old password until I don't close mail client. If I run again thunderbird then server ask me for new password. Is there any command configuration to check password for every e-mail send or session idle? I have the same problem with imap (dovecot). Even if I change password for user I can read email in thunderbird until I close it. Regards, Tomasz
Re: Postfix SASL auth - client alway sent e-mail even password change until I run again client app
Tomasz Kopczy?ski: > Hi. > I configured client auth for sending emails. Everythings work fine but > when I change password for user I still can send email from outlook or > thunderbird with old password until I don't close mail client. If I run > again thunderbird then server ask me for new password. Is there any > command configuration to check password for every e-mail send or session > idle? > > I have the same problem with imap (dovecot). Even if I change password > for user I can read email in thunderbird until I close it. How do you know that you changed the SASL PASSWORD for the user? Wietse
Re: Postfix SASL auth - client alway sent e-mail even password change until I run again client app
I know because if I changed password and I run again program then server want new password, old password not work, and I can login in to the webmail with new password. Tomasz W dniu 2014-10-08 14:45, Wietse Venema pisze: Tomasz Kopczy?ski: Hi. I configured client auth for sending emails. Everythings work fine but when I change password for user I still can send email from outlook or thunderbird with old password until I don't close mail client. If I run again thunderbird then server ask me for new password. Is there any command configuration to check password for every e-mail send or session idle? I have the same problem with imap (dovecot). Even if I change password for user I can read email in thunderbird until I close it. How do you know that you changed the SASL PASSWORD for the user? Wietse
Re: Postfix SASL auth - client alway sent e-mail even password change until I run again client app
On 10/8/2014 7:54 AM, Tomasz Kopczyński wrote: > I have the same problem with imap (dovecot). Even if I change password > for user I can read email in thunderbird until I close it. You didn't say, but since you mentioned dovecot, are you using dovecot sasl? If so, maybe: http://wiki2.dovecot.org/Authentication/Caching helps...
Re: Postfix SASL auth - client alway sent e-mail even password change until I run again client app
Am 08.10.2014 um 14:55 schrieb Charles Marcus: On 10/8/2014 7:54 AM, Tomasz Kopczyński wrote: I have the same problem with imap (dovecot). Even if I change password for user I can read email in thunderbird until I close it. You didn't say, but since you mentioned dovecot, are you using dovecot sasl? If so, maybe: http://wiki2.dovecot.org/Authentication/Caching even without cache changing the password don't close existing connections - i had AppleMail cients try to store a wrongly selected 4 GB video in the drafts folder again and again, changed password and still OOM killers because existing client->dbmail-process connections until hard restart the service
Before-Queue forwarding
Hi, my postfix has to forward some incoming mails to another SMTP server not under my control. This SMTP server has filters and limits that differ from my own, and will reject some mail that my postfix accepted. When this happens my postfix has to send a bounce mail back to the original sender. Which in most cases means I'm sending backscatter to a forged address... I would like to do the forwarding in the same way the before-queue content filter feature works. Hold the original SMTP connection open, open a new SMTP connection to the destination server and try to deliver the mail, pass any status code back to the original connection. Is this in any way possible? Do you think this is a good idea? Best regards, Lothar Gesslein -- Lothar Gesslein Linux Consultant Mail: gessl...@b1-systems.de B1 Systems GmbH Osterfeldstraße 7 / 85088 Vohburg / http://www.b1-systems.de GF: Ralph Dehner / Unternehmenssitz: Vohburg / AG: Ingolstadt,HRB 3537 signature.asc Description: OpenPGP digital signature
Re: postscreen log scanner script updated
Hi,
Am 2014-09-29 18:18, schrieb Mike.:
On 9/29/2014 at 10:44 AM Mike. wrote:
|I cleaned up my pslogscan.sh script a bit. Aside from some general
|cleanup, I did some re-formatting of the output to make it look a
bit
|cleaner, and allow for some flexibility in display widths. I also
|went from linear processing of multiple items to loop processing of
|those items.
[snip]
=
Someone found a typo that the FreeBSD shell seems to be OK with, but
Debian (wheezy) dislikes.
Version 1.8 has been uploaded to
http://archive.mgm51.com/sources/pslogscan.html
If you don't want to download, here's the description:
I fixed line 144 with :
if [ ${DeepProtocolTestsEnabled} = "no" ] ; then
instead of
if [ ${DeepProtocolTestsEnabled} == "no" ] ; then
(I guess I've been programming in c too much of late. :) )
Thanks to AE for the bug report.
theres also an
net-mail/postfix-logwatch
http://logreporters.sourceforge.net/
marko
Re: Before-Queue forwarding
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 10/8/2014 10:54 AM, Lothar Gesslein wrote: > Hi, > > my postfix has to forward some incoming mails to another SMTP > server not under my control. This SMTP server has filters and > limits that differ from my own, and will reject some mail that > my postfix accepted. When this happens my postfix has to send a > bounce mail back to the original sender. > > Which in most cases means I'm sending backscatter to a forged > address... > > I would like to do the forwarding in the same way the > before-queue content filter feature works. Hold the original > SMTP connection open, open a new SMTP connection to the > destination server and try to deliver the mail, pass any status > code back to the original connection. > > Is this in any way possible? Do you think this is a good idea? > > Best regards, Lothar Gesslein > The problem is "some incoming mail". Postfix has no method to selectively send some mail to the smtpd_proxy_filter, and pass other mail through (or to a different proxy). Yes, it would be a good idea in this case to selectively proxy messages to the external host, but it's not currently possible. You're stuck in a nasty position. Your best course of action is to get the postmaster at the other server to whitelist you. If you have C programming skills, it might be possible to enhance the existing smtpd_proxy_filter speed_adjust feature to select the proxy based on some message property. I have no idea off-hand how complex that might be. -- Noel Jones -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.22 (MingW32) iQEcBAEBAgAGBQJUNWqdAAoJEJGRUHb5Oh6gbrsH/jdTT6xwvfT+9Vj3CXt3wFYY Jf/EQGWCXP1OJp8W3sULqueCacm4e8At0fn2nu4+f9LwL+8VeKHs9xpKSF0o9g35 BpXM5APhgrjl9t97+7Mo64dP8athK47qFRLP2rmPYeDFm0BXIi8YZpH/ZC9TUzp6 q3aFPs6ZlAcasMSnSWI8+3P2LiWEzyVDsHx3b+Ebr9WNMxMAxc1emriqM/Wgri/E SlMXtw11Ht4fvNz5Ztqy9XtXm/69hf1MNBWZlbM0bg3B/ijKbuB8k6/n7OhFbF3R 4/QfXovPHqcJoQ6s6PUH8i555tMASNzIt3TtErz/s9AY+DaFkSdBv4jtzpyDUSI= =VdoM -END PGP SIGNATURE-
Re: Before-Queue forwarding
Noel Jones: > The problem is "some incoming mail". Postfix has no method to > selectively send some mail to the smtpd_proxy_filter, and pass > other mail through (or to a different proxy). > > Yes, it would be a good idea in this case to selectively proxy > messages to the external host, but it's not currently possible. > > You're stuck in a nasty position. Your best course of action is to > get the postmaster at the other server to whitelist you. > > If you have C programming skills, it might be possible to enhance > the existing smtpd_proxy_filter speed_adjust feature to select the > proxy based on some message property. I have no idea off-hand how > complex that might be. You could try to repurpose the speed_adjust feature as follows: 1) A new function smtpd_proxy_control() to change a property of an existing proxy filter handle (such as the destination server host and port). This function be patterned after vstream_control() or any similar function in Postfix. 2) A new smtpd access(5) action (PROXY_FILTER host:port) that invokes the new function to change the destination server host and port. But that does not mean that it will work well. The proxy filter client does not implement TLS or SASL authentication. It is designed to be used with a local filter, not a remote SMTP server. It will not work when Postfix announces features such as SMTPUTF8 or DSN that the remote SMTP server does not implement. The remote SMTP server will reject MAIL FROM or RCPT TO commands that the Postfix SMTP server has already accepted. It will not work when the remote SMTP server rejects a recipient selectively. As documented with the speed_adjust feature, rejecting or accepting all recipients is OK. Selective recipient rejection cannot be supported with speed_adjust, because the Postfix SMTP eerver has already accepted the recipients. Wietse
Policy Server (action=PREPEND ) Questions (redux)
I posted these questions recently, but either nobody saw my posting or else nobody thought that these questions wre worth of a reply. On the chance that it was the former, I am posting these questions again... because I still do need answers. == I'm building a new policy server, and I have some questions about the protocol. "Tagging" of incoming messages... so that they may be specially handled by post-delivery tools (e.g. procmail and others) is a useful feature. And I hope to make use of "action=PREPEND " responses in my policy server to perform such tagging. All of my (3) questions below relate to such tagging. 1) With regards to the "action=PREPEND " response that can be yielded by a policy server, is there any way that this can be used to inject more than one new header into the message currently being processed? For example, let's say that I want to build a policy server that injects the following new headers into every message it processes: X-Foo: bar X-Bar: foo Is there a way to do that, within the existing protocol? Or must I create, install, and activate one new policy server for each separate header that I want to attach? (I was thinking that it might be Nice if the protocol allowed for the possibility of, say, a literal "\n" within the portion of a PREPEND response. If that were supported, then I could clump together as many additional headers as I liked into a single action=PREPEND response sent from the policy server.) 2) Also with respect to the "action=PREPEND " response that can be returned by a policy server, I am wondering if Postfix undertakes any formatting of the material before it prepends it to the current message. In particular, I am wondering if Postfix will automagically perform any folding of the new header being prepended to the message, i.e. at points containg whitespace within the header. 3) I had hoped to be able to have my new policy server run, once only, for each incoming message, at MAIL FROM time. So naturally. I inserted the rule to invoke it underneath my smtpd_sender_restrictions in my main.cf file. However when I had the policy server log (to a file) all of the material in the requests it was receiving from Postfix I was, confused, at first to find that in the requests it was receiving, the protocol_state parameter was always set to "RCPT" rather than "MAIL". Then I realized the essential cause of this, i.e.: smtpd_delay_reject = yes Obviously, and as documented, smtpd_delay_reject was causing the "restrictions" listed in my smtpd_sender_restrictions list to be delayed until the RCPT TO phase. That delay, in and of itself is not really a problem for me. What _is_ a bit of a problem is the fact that smtpd_delay_reject doesn't merely cause anything listed under smtpd_sender_restrictions to be delayed until such time as the _first_ RCPT TO is seen, but rather it causes each of the things listed under smtpd_sender_restrictions to be reevaluated, once for each RCPT TO. Thus, as I have just seen, if an incoming message has multiple recipients, a policy server which is specified as part of smtpd_sender_restrictions will run multiple times on the same single message. That in turn implies that if, for example, the policy server always send this response back to Postfix: action=PREPEND X-Foo: bar then an incoming message which has multiple local recipients will end up having the following prepended: X-Foo: bar X-Foo: bar ... For my purposes, this is sub-optimal. Obviously, I could solve my multiple-redundant-injected-header problem by setting "smtpd_delay_reject=no", so that my policy server _would_ in fact be invoked, only once for each message, at MAIL FROM time. But I am rather reluctant to make this change because I'm not sure what the full implications of doing that might be. The documentation is clear that some SMTP clients become confused if told to go away too soon (i.e. immediately after MAIL FROM) but does not otherwise elaborate. Given that I wish to have my policy server execute only once per each MAIL FROM, _and_ given that I do not wish to lose the benefits of the semantics of smtpd_delay_reject, is the proper solution here for me to move any and all restrictions that I currently have listed under smtpd_client_restrictions, smtpd_helo_restrictions, and smtpd_sender_restrictions and put those all under smtpd_recipient_restrictions (preserving their proper order, of course) *except* for the one ``restriction'', listed within my smtpd_sender_restrictions that causes the invocation of my tagging policy server, and then, finally set smtpd_delay_reject to "no"? It would seem that that exact set of changes should allow my policy server to run at MAIL FROM time while still preserving all of my other restrictions *and* insuring that those are only evaluated at RCPT TO time, thus allowing me to have my cake and eat i
Another policy server question...
The SMTPD_POLICY_README file says: "In case of trouble the policy server must not send a reply. Instead the server must log a warning and disconnect. Postfix will retry the request at some later time." Ummm... I can easly handle the "log a warning" part, but... As I understand it, a Postfix policy server is supposed to be reading incoming requests from stdin. How exactly does one "disconnect" from stdin? I mean other than by calling exit() ?
Re: Policy Server (action=PREPEND ) Questions (redux)
On 10/8/2014 8:11 PM, Ronald F. Guilmette wrote: > I posted these questions recently, but either nobody saw my posting > or else nobody thought that these questions wre worth of a reply. > > On the chance that it was the former, I am posting these questions > again... because I still do need answers. > > == > I'm building a new policy server, and I have some questions about > the protocol. > > "Tagging" of incoming messages... so that they may be specially > handled by post-delivery tools (e.g. procmail and others) is a useful > feature. And I hope to make use of "action=PREPEND " responses > in my policy server to perform such tagging. All of my (3) questions > below relate to such tagging. > > > 1) With regards to the "action=PREPEND " response that can be > yielded by a policy server, is there any way that this can be used > to inject more than one new header into the message currently being The "one query, one response" model from the rest of postfix holds true for the policy service interface too. > > 2) Also with respect to the "action=PREPEND " response that can > be returned by a policy server, I am wondering if Postfix undertakes > any formatting of the material before it prepends it to the No text formatting is done. > 3) I had hoped to be able to have my new policy server run, once > only, for each incoming message, at MAIL FROM time. So naturally. > I inserted the rule to invoke it underneath my smtpd_sender_restrictions > in my main.cf file. However when I had the policy server log (to a > file) all of the material in the requests it was receiving from > Postfix I was, confused, at first to find that in the requests it > was receiving, the protocol_state parameter was always set to > "RCPT" rather than "MAIL". Then I realized the essential cause of > this, i.e.: > > smtpd_delay_reject = yes > > Obviously, and as documented, smtpd_delay_reject was causing the > "restrictions" listed in my smtpd_sender_restrictions list to be > delayed until the RCPT TO phase. Yes, this is documented. > > That delay, in and of itself is not really a problem for me. What > _is_ a bit of a problem is the fact that smtpd_delay_reject doesn't > merely cause anything listed under smtpd_sender_restrictions to be > delayed until such time as the _first_ RCPT TO is seen, but rather > it causes each of the things listed under smtpd_sender_restrictions > to be reevaluated, once for each RCPT TO. Yes, this is an implementation artifact. I don't know if it's worth fixing since it rarely causes an issue. Typically, policy services that only need to be run once are put in smtpd_data_restrictions. One thing to be aware of with smtpd_data_restrictions is the recipient list will be empty for multirecipient mail, but that doesn't sound as if it's a problem for your application since you appear to be only concerned with the sender. -- Noel Jones
Re: Another policy server question...
On 10/8/2014 8:17 PM, Ronald F. Guilmette wrote: > The SMTPD_POLICY_README file says: > > "In case of trouble the policy server must not send a reply. Instead the > server > must log a warning and disconnect. Postfix will retry the request at some > later > time." > > > Ummm... > > I can easly handle the "log a warning" part, but... > > As I understand it, a Postfix policy server is supposed to be reading > incoming requests from stdin. > > How exactly does one "disconnect" from stdin? I mean other than by > calling exit() ? > Exiting is sufficient. -- Noel Jones
Re: Policy Server (action=PREPEND ) Questions (redux)
In message <543614e5.6060...@megan.vbhcs.org>, Noel Jones wrote: >On 10/8/2014 8:11 PM, Ronald F. Guilmette wrote: >> That delay, in and of itself is not really a problem for me. What >> _is_ a bit of a problem is the fact that smtpd_delay_reject doesn't >> merely cause anything listed under smtpd_sender_restrictions to be >> delayed until such time as the _first_ RCPT TO is seen, but rather >> it causes each of the things listed under smtpd_sender_restrictions >> to be reevaluated, once for each RCPT TO. > >Yes, this is an implementation artifact. I don't know if it's worth >fixing since it rarely causes an issue. I completely agree, given what you said next... >Typically, policy services that only need to be run once are put in >smtpd_data_restrictions. A! To be honest, I never even knew that there even _was_ such a restriction class until just now! Thank you very much! I believe that will solve the multiple evaluation problem for me. And I guess that executing my policy server as part of smtpd_data_restrictions will also allow me to turn back on the smtpd_delay_reject setting... which I had turned off, for the time being, in order to avoid the multiple evaluation problem.
Small Enhancement Request
This is a request for a very minor change to the semantics of the PREPEND result that can be returned from policy servers and/or from specific entries within an access(5) lookup table. It would be maximally convenient if the subject could be interpolated in the following trivial way: Any literal "\n" (backslash-n) sequence withing is replaced with an actual newline character. This trivial change would allow prepending of multiple headers to the current e-mail message. This capability would be useful in the context of systems that tag incoming messages for later analysis and/or special processing by tools external to the mail server. Alternatively, given that the Postfix policy server protocol theoretically allows for the possibility of a policy server yielding multiple "action=PREPEND " results in response to any given single request (from Postfix), it would be Nice if Postfix would in fact accept a sequence of multiple such responses from a policy server in response to a single request.
Re: Another policy server question...
In message <54361549.5050...@megan.vbhcs.org>, Noel Jones wrote: >On 10/8/2014 8:17 PM, Ronald F. Guilmette wrote: >> The SMTPD_POLICY_README file says: >> >> "In case of trouble the policy server must not send a reply. Instead the ser >ver >> must log a warning and disconnect. Postfix will retry the request at some la >ter >> time." >> >> >> Ummm... >> >> I can easly handle the "log a warning" part, but... >> >> As I understand it, a Postfix policy server is supposed to be reading >> incoming requests from stdin. >> >> How exactly does one "disconnect" from stdin? I mean other than by >> calling exit() ? >> > >Exiting is sufficient. The SMTPD_POLICY_README file should be edited in a way so as to make that clear. The current wording is quite entirely perplexing. "Disconnect" is quite obviously the wrong word to use in this context.
