Re: [courier-users] courier TLS_PROTOCOL compatibility
Hi. On Thursday 13 March 2008, Bernd Wurst wrote: > Hi. > > On Thursday 13 March 2008, Sam Varshavchik wrote: > > Received: from www.courier-mta.com ([216.254.115.190]) by > > mail.sourceforge.net with esmtps (SSLv3:AES256-SHA:256) (Exim 4.44) id > > 1JZDuV-0008Af-LZ for courier-users@lists.sourceforge.net; Tue, 11 Mar > > 2008 16:29:34 -0700 > > > > I have TLS_PROTOCOL=SSL3 set in courierd > > I'm pretty sure that setting this to SSL23 instead (and denying SSL2 as I > described) would have made the connection to use TLSv1 (if sourceforge > supports it). Received: from zucker.schokokeks.org ([85.10.204.247]) by mail.sourceforge.net with esmtps (TLSv1:AES256-SHA:256) (Exim 4.44) id 1JZgE5-0006iv-4F for courier-users@lists.sourceforge.net; Wed, 12 Mar 2008 22:43:38 -0700 confirmed. :) regards, Bernd -- If Bill Gates had a penny for every time Windows crashed... ...oh wait, he does. - Quelle unbekannt signature.asc Description: This is a digitally signed message part. - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/___ courier-users mailing list courier-users@lists.sourceforge.net Unsubscribe: https://lists.sourceforge.net/lists/listinfo/courier-users
Re: [courier-users] courier TLS_PROTOCOL compatibility
Hi. On Thursday 13 March 2008, Sam Varshavchik wrote: > Received: from www.courier-mta.com ([216.254.115.190]) by > mail.sourceforge.net with esmtps (SSLv3:AES256-SHA:256) (Exim 4.44) id > 1JZDuV-0008Af-LZ for courier-users@lists.sourceforge.net; Tue, 11 Mar 2008 > 16:29:34 -0700 > > I have TLS_PROTOCOL=SSL3 set in courierd I'm pretty sure that setting this to SSL23 instead (and denying SSL2 as I described) would have made the connection to use TLSv1 (if sourceforge supports it). Sure, my statement is not necessarily valid for GnuTLS but in openssl context, this is fact. So the question is, why do you manually "downgrade" your connection to SSLv3 when you could have used TLSv1? ;-) regards, Bernd -- Math and alcohol don't mix. Don't drink and derive! signature.asc Description: This is a digitally signed message part. - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/___ courier-users mailing list courier-users@lists.sourceforge.net Unsubscribe: https://lists.sourceforge.net/lists/listinfo/courier-users
Re: [courier-users] courier-authlib and cn attribute
Mike Kenny wrote: > They suspect that it i triggering a memory leak. Which they admit is > not a problem with courier-authlib and should e resolved by Novell. In > the meantime we want a) to avoid this leak and b) to confirm the cause > (so as to assist Novell in rectifying it. > > BTW, why do you say they are 'idiots'? For removing the cn attribute > or for believing that querying it could cause problems? or both? If they suspect that it's triggering a memory leak, they can set up a test instance, and run "ldapsearch" in a loop. Once with requests for "cn", and again without (after restarting). If a memory leak were that easily triggered, there's no reason to "fear" that the queries are causing problems; they can be certain with very little work. It's unlikely that queries for non-existent attributes would cause a memory leak. Many clients ask for attributes that usually don't exist. It's normal. - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ courier-users mailing list courier-users@lists.sourceforge.net Unsubscribe: https://lists.sourceforge.net/lists/listinfo/courier-users
[courier-users] Courier 20080312
Download: http://www.courier-mta.org/download.php
New development build of Courier and Courier-IMAP packages.
Changes:
* Several portability fixes.
* Strip any trailing periods in sender and recipient addresses' domain names.
* imap: Optionally disable maildir ownership sanity check, controlled by a
new setting: IMAP_MAILBOX_SANITY_CHECK
* webmail: Autorenaming of the Sent folder can be turned off in preferences.
* Fix %{ir} macro expansion in SPF records.
* Update default SSL/TLS settings to be more liberal by default. Affects new
installs only, will not touch existing configuration on upgrade. Thanks to
Gordon Messmer for doing the footwork.
pgporkgpjFJp0.pgp
Description: PGP signature
-
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/___
courier-users mailing list
courier-users@lists.sourceforge.net
Unsubscribe: https://lists.sourceforge.net/lists/listinfo/courier-users
Re: [courier-users] More hooks like loginexec?
Hello Ben, >So how about a simple web interface with a button that will instigate a >run of the fetchmail? that's what I was going to do, if nothing better came up. But it's much too clumsy for my taste. >Or a frequent (per-minute) cron job that looks at the atime of your >maildir, and does same? Now here is an idea that I like much better ... :-) Thanks! Hmmm ... maybe I could even use the FAM. Have to do some reading ... But the best solution would still be some hook like loginexec. Regards, Norbert - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ courier-users mailing list courier-users@lists.sourceforge.net Unsubscribe: https://lists.sourceforge.net/lists/listinfo/courier-users
Re: [courier-users] More hooks like loginexec?
Hello Malcolm, >I'd go with a small perl script hooked into syslog. The script would mostly >just print all it's input, but when it sees the LOGIN message, it also >triggers the fetchmail. wouldn't help. The client (thunderbird) only does a login once, not for each poll. And for the login I can use "loginexec" which is much less trouble then messing with the syslog. >Alternatively, you could create a more complex scheme that looks at the >timestamps on the Maildir entries, but that would be much more complex since >it would have to ignore artifacts of itself. Sounds like a good idea, if I can't use propper hooks. >Other options: a "special" Maildir directory for which a modification to a >file would trigger the fetchmail, so just copy any old message to it and the >fetch would occur. > >Or a special address on the server (e.g. "fetchmail-userid") which would >trigger a fetch if you send anything to it (using maildrop). Too cumbersome and dangerous. If I accidently move the mail instead of copying, it would be lost ... A web interface to trigger fetchmail would be still klutzy but cleaner. Regards, Norbert - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ courier-users mailing list courier-users@lists.sourceforge.net Unsubscribe: https://lists.sourceforge.net/lists/listinfo/courier-users
Re: [courier-users] More hooks like loginexec?
> -Original Message- > From: Norbert Schmidt > Sent: Wednesday, March 12, 2008 5:02 PM > >So why not set up a cron job to poll your mail every ten minutes, or > >something reasonable? Is there a good reason why its > execution must be > >tied directly to IMAP polls? > > what's reasonable depends on the context. ;) I'd go with a small perl script hooked into syslog. The script would mostly just print all it's input, but when it sees the LOGIN message, it also triggers the fetchmail. Alternatively, you could create a more complex scheme that looks at the timestamps on the Maildir entries, but that would be much more complex since it would have to ignore artifacts of itself. Other options: a "special" Maildir directory for which a modification to a file would trigger the fetchmail, so just copy any old message to it and the fetch would occur. Or a special address on the server (e.g. "fetchmail-userid") which would trigger a fetch if you send anything to it (using maildrop). > Regards, > Norbert Malc. - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ courier-users mailing list courier-users@lists.sourceforge.net Unsubscribe: https://lists.sourceforge.net/lists/listinfo/courier-users
Re: [courier-users] More hooks like loginexec?
Norbert Schmidt wrote at 1:02 AM (+0100) on 3/13/08: >Now consider the following situation: I'm on the phone with someone and >he tells me that he sent me an email with some data to talk about. If I >can't poll the mail manually we may have to wait maybe 10 minutes until >it is fetched automatically. What should I tell him? "Sorry, I can't >fetch my mail manually, I'll call you back in 10 minutes or we could >discuss the weather while we're waiting ..." sounds pretty lame. So how about a simple web interface with a button that will instigate a run of the fetchmail? Or a frequent (per-minute) cron job that looks at the atime of your maildir, and does same? -b -- Ben Kennedy (chief magician) zygoat creative technical services http://www.zygoat.ca - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ courier-users mailing list courier-users@lists.sourceforge.net Unsubscribe: https://lists.sourceforge.net/lists/listinfo/courier-users
Re: [courier-users] More hooks like loginexec?
Hello Ben, >So why not set up a cron job to poll your mail every ten minutes, or >something reasonable? Is there a good reason why its execution must be >tied directly to IMAP polls? what's reasonable depends on the context. ;) When I'm offline, once a day (or not at all ;-)) is quite reasonable. For normal operation ten minutes is ok for my main account (that's actually what I use now ...). For my other accounts an hour is enough. But once in a while I exchange mails "live" with someone. Then I don't want any delay at all. I still use a simple mail client and poll my accounts directly and I can do all this. The major problem with my current setup is that I can use only one computer for mail or have to do very careful copying. That's why I want my own local IMAP server for consistent mail available on all my computers. Now consider the following situation: I'm on the phone with someone and he tells me that he sent me an email with some data to talk about. If I can't poll the mail manually we may have to wait maybe 10 minutes until it is fetched automatically. What should I tell him? "Sorry, I can't fetch my mail manually, I'll call you back in 10 minutes or we could discuss the weather while we're waiting ..." sounds pretty lame. Regards, Norbert - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ courier-users mailing list courier-users@lists.sourceforge.net Unsubscribe: https://lists.sourceforge.net/lists/listinfo/courier-users
Re: [courier-users] courier TLS_PROTOCOL compatibility
Gordon Messmer writes: Sam Varshavchik wrote: Gordon Messmer writes: The point that I tried to illustrate, after doing the testing, was that there's no point to that setting. Nothing can be made better by changing it. I disagree. One of the reasons -- not the only one, but one of the factors -- that precipitated this whole discussion is because someone had made a reasonable argument that, for policy reasons, they wanted to disable SSL2. Additionally, it is a reasonable position to have a policy that, for example, allowed only DH-based ciphers. As such, access to the underlying SSL knobs is needed. Sure, I agree, and we've established that this can be done using TLS_CIPHER_LIST. The TLS_PROTOCOL setting, on the other hand, will only create situations where most connections won't work. When set to TLS1 or SSL3, only an identically configured client will connect. For whatever reason, even courierd using SSL23, which should be compatible in theory, won't connect to an smtpd that's using SSL3 as its protocol setting. The only thing is that TLS_PROTOCOL is a mandatory setting. It's not optional, in the OpenSSL context. If it's unset, Courier just uses the default setting. This is NOT an optional setting. This setting control which function creates the initial OpenSSL SSL context structure. This setting controls whether SSLv23_method(), TLSv1_method(), or SSLv3_method() creates a new SSL context structure. That's a mandatory step in initializing an SSL session. I do see now where the confusion comes from. I'm fairly sure that at some point in the past, OpenSSL's docs indicates that SSLv23_method() just sets up the SSL context for SSL 2 and SSL 3, period. The current version's documentation now says that it also adds TLS 1. So there. The wayback machine is currently down :-( so I can't confirm if I remember it right. That being the case, the setting is useless unless someone wants to establish a tunnel between two courier servers, and those servers aren't going to connect to anything except each other. That's hardly a good enough reason to keep that setting. Even less so since admins can use TLS_CIPHER_LIST to accomplish their goal. TLS_PROTOCOL is just extra cruft that will cause headache for the people who set it, and needlessly adds to the code base. I'm afraid that most of my daylight hours are spent doing things that allow me to spend only a few hours a day answering my mail. Those are the facts of life, that's simply just the way things are. It's not that I do not appreciate you taking the time to do some research here -- it is very much appreciated -- it's just that a concise, capsule summary of your findings would've worked better for me. The summary is: Three days ago, I thought the TLS_PROTOCOL setting was a good idea, and useful toward getting rid of SSL2, and its security deficiencies. After actually looking at the effects of using it, I've reversed that opinion. It's the wrong manner in which to disable SSL2 support. It breaks interoperability with clients that have reasonable SSL configurations. The only thing that remains unclear is what should be the defaults on the client side. There are two distinct cases here: protocol-over-SSL, and STARTTLS-after-protocol, that might require different default settings. Do you mean "courierd->courieresmtp" client, or imap clients? My first guess would be that they'd work with the same settings: SSL23 method, secure cipher list. I haven't gotten around to that set of tests, though. I mean courieresmtp. As a data point, I have no problems sending mail to Sourceforge. From one of my recent headers: Received: from www.courier-mta.com ([216.254.115.190]) by mail.sourceforge.net with esmtps (SSLv3:AES256-SHA:256) (Exim 4.44) id 1JZDuV-0008Af-LZ for courier-users@lists.sourceforge.net; Tue, 11 Mar 2008 16:29:34 -0700 I have TLS_PROTOCOL=SSL3 set in courierd, the setting that takes effect for courieresmtp connection. … But, I just checked, and I'm currently running a GnuTLS-based build, so that may be a completely different issue. pgpJaYKdSgB8u.pgp Description: PGP signature - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/___ courier-users mailing list courier-users@lists.sourceforge.net Unsubscribe: https://lists.sourceforge.net/lists/listinfo/courier-users
Re: [courier-users] More hooks like loginexec?
Norbert Schmidt wrote at 11:52 PM (+0100) on 3/12/08: >And I don't think anybody else would be pleased if I configure >fetchmail to poll my remote mail every few seconds, even when I'm >sleeping ... ;) So why not set up a cron job to poll your mail every ten minutes, or something reasonable? Is there a good reason why its execution must be tied directly to IMAP polls? -b -- Ben Kennedy (chief magician) zygoat creative technical services http://www.zygoat.ca - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ courier-users mailing list courier-users@lists.sourceforge.net Unsubscribe: https://lists.sourceforge.net/lists/listinfo/courier-users
Re: [courier-users] More hooks like loginexec?
Hello Sam, >Here's a question for you. Your mail client periodically checks for new >mail. Now, a new mail check will not simply be a quick, nearly instantaneous >operation, the server will now has to run an external hook program, and >fetchmail may take quite a bit of time to log on to an external mailbox, and >download new mail, and the IMAP server has to wait until it's done, before >sending a response. well, one solution would be to just trigger the fetching and do it in the background while the server reports the current state: nothing new or the stuff that came in with the last poll. >So, when your mail client now starts freezing, for 10-15 seconds at a time, >and not responding to your commands, are you going to blame the IMAP server >for this? Of course not. :) But the alternative is to wait until fetchmail does another automatic poll. So I'ld rather have to wait a few seconds for the server to complete the request than sit around idling several minutes, when I know there is an email out there that I want to read asap. And I don't think anybody else would be pleased if I configure fetchmail to poll my remote mail every few seconds, even when I'm sleeping ... ;) Regards, Norbert - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ courier-users mailing list courier-users@lists.sourceforge.net Unsubscribe: https://lists.sourceforge.net/lists/listinfo/courier-users
Re: [courier-users] about pythonfilter again
Sergio Bortsov a écrit : Hello Gordon, Wednesday, March 12, 2008, 6:50:09 PM, you wrote: Sergio Bortsov wrote: /kernel: pid 9591 (python), uid 100: exited on signal 11 (core dumped) What platform is this? freebsd 4.8 perl5.10 spamassasin 3.2.4 If you have the core file, I might be able to examine it and see what happened. only this I think Mar 11 16:23:29 colo /kernel: pid 3807 (python), uid 100: exited on signal 11 Mar 11 16:23:42 colo /kernel: pid 3767 (python), uid 100: exited on signal 11 (core dumped) [...] find / -name core xD HTH. Jerome Blion. - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/___ courier-users mailing list courier-users@lists.sourceforge.net Unsubscribe: https://lists.sourceforge.net/lists/listinfo/courier-users
Re: [courier-users] about pythonfilter again
Hello Gordon, Wednesday, March 12, 2008, 6:50:09 PM, you wrote: > Sergio Bortsov wrote: >> /kernel: pid 9591 (python), uid 100: exited on signal 11 (core dumped) >> > What platform is this? freebsd 4.8 perl5.10 spamassasin 3.2.4 > If you have the core file, I might be able to > examine it and see what happened. only this I think Mar 11 16:23:29 colo /kernel: pid 3807 (python), uid 100: exited on signal 11 Mar 11 16:23:42 colo /kernel: pid 3767 (python), uid 100: exited on signal 11 (core dumped) Mar 11 16:23:43 colo /kernel: pid 1160 (python), uid 100: exited on signal 11 Mar 11 16:23:51 colo /kernel: pid 3914 (python), uid 100: exited on signal 11 (core dumped) Mar 12 10:43:22 colo /kernel: pid 7043 (python), uid 100: exited on signal 11 Mar 12 10:43:22 colo /kernel: pid 7026 (python), uid 100: exited on signal 11 (core dumped) Mar 12 10:43:22 colo /kernel: pid 7050 (python), uid 100: exited on signal 11 (core dumped) Mar 12 10:43:23 colo /kernel: pid 7057 (python), uid 100: exited on signal 11 (core dumped) Mar 12 10:43:26 colo /kernel: pid 7085 (python), uid 100: exited on signal 11 (core dumped) Mar 12 10:43:33 colo /kernel: pid 7167 (python), uid 100: exited on signal 11 (core dumped) Mar 12 10:43:37 colo /kernel: pid 7202 (python), uid 100: exited on signal 11 (core dumped) Mar 12 10:43:38 colo /kernel: pid 7217 (python), uid 100: exited on signal 11 (core dumped) Mar 12 10:43:43 colo /kernel: pid 7254 (python), uid 100: exited on signal 11 (core dumped) Mar 12 10:43:46 colo /kernel: pid 7289 (python), uid 100: exited on signal 11 (core dumped) Mar 12 10:43:49 colo /kernel: pid 7307 (python), uid 100: exited on signal 11 (core dumped) Mar 12 10:43:58 colo /kernel: pid 7400 (python), uid 100: exited on signal 11 (core dumped) Mar 12 10:43:59 colo /kernel: pid 7405 (python), uid 100: exited on signal 11 (core dumped) Mar 12 10:44:22 colo /kernel: pid 7643 (python), uid 100: exited on signal 11 (core dumped) Mar 12 10:44:24 colo /kernel: pid 7683 (python), uid 100: exited on signal 11 Mar 12 10:44:24 colo /kernel: pid 7668 (python), uid 100: exited on signal 11 (core dumped) Mar 12 10:44:26 colo /kernel: pid 7705 (python), uid 100: exited on signal 11 (core dumped) Mar 12 10:44:28 colo /kernel: pid 7739 (python), uid 100: exited on signal 11 (core dumped) Mar 12 10:44:28 colo /kernel: pid 7742 (python), uid 100: exited on signal 11 (core dumped) Mar 12 10:44:40 colo /kernel: pid 7942 (python), uid 100: exited on signal 11 Mar 12 10:44:40 colo /kernel: pid 7922 (python), uid 100: exited on signal 11 (core dumped) Mar 12 10:44:43 colo /kernel: pid 7970 (python), uid 100: exited on signal 11 (core dumped) Mar 12 10:44:44 colo /kernel: pid 7988 (python), uid 100: exited on signal 11 Mar 12 10:44:45 colo /kernel: pid 7986 (python), uid 100: exited on signal 11 (core dumped) Mar 12 10:44:45 colo /kernel: pid 7992 (python), uid 100: exited on signal 11 (core dumped) Mar 12 10:45:05 colo /kernel: pid 8172 (python), uid 100: exited on signal 11 Mar 12 10:45:06 colo /kernel: pid 8166 (python), uid 100: exited on signal 11 (core dumped) Mar 12 10:45:40 colo /kernel: pid 8535 (python), uid 100: exited on signal 11 (core dumped) -- Best regards, Sergio Bortsovmailto:[EMAIL PROTECTED] ISP Neonet 8(098)4491155 8(032)2987593 - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ courier-users mailing list courier-users@lists.sourceforge.net Unsubscribe: https://lists.sourceforge.net/lists/listinfo/courier-users
Re: [courier-users] dot-courier: external program related questions...
Hi. On Wednesday 12 March 2008, Gordon Messmer wrote: > > 2. It seems that anything that the external program writes to it > > STDERR just disappears. Is that right? Is there a way for the external > > program to supply text to be used in the error/bounce message? > I don't believe so. stderr goes to the log files, stdout is the error string for the generated bounce message. In this part, courier behaves like QMail, if you know that one. regards, Bernd -- You know it's going to be a bad day when your twin brother forgets your birthday. signature.asc Description: This is a digitally signed message part. - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/___ courier-users mailing list courier-users@lists.sourceforge.net Unsubscribe: https://lists.sourceforge.net/lists/listinfo/courier-users
Re: [courier-users] about pythonfilter again
Sergio Bortsov wrote: > /kernel: pid 9591 (python), uid 100: exited on signal 11 (core dumped) > What platform is this? If you have the core file, I might be able to examine it and see what happened. - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ courier-users mailing list courier-users@lists.sourceforge.net Unsubscribe: https://lists.sourceforge.net/lists/listinfo/courier-users
Re: [courier-users] dot-courier: external program related questions...
On Mar 12, 2008, at 12:35 PM, Gordon Messmer wrote: > <...> Gordon, thank you for the info! I should have thought of system error codes! --ravi - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ courier-users mailing list courier-users@lists.sourceforge.net Unsubscribe: https://lists.sourceforge.net/lists/listinfo/courier-users
[courier-users] makemime from [EMAIL PROTECTED] to [EMAIL PROTECTED]
I'm trying to modify some behavior of courier faxmail. One is my problems, send new fax to apropriate user INBOX. At first time I simply want to make a mime mail message but I always have message that the mail is wrong formatted and lookup RFC822. Of course I can doit, but I need to save some time. Could some one to help me giving the right form of running the makemime command, for a simple test mail which is sent from [EMAIL PROTECTED] to [EMAIL PROTECTED], content is a simple text, for example: "This is a test message #0002" How should be incoked makemime for this simple message? Thanks in advance. - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ courier-users mailing list courier-users@lists.sourceforge.net Unsubscribe: https://lists.sourceforge.net/lists/listinfo/courier-users
Re: [courier-users] dot-courier: external program related questions...
ravi wrote: > 1. The dot-courier man page says that exit codes 64, 65, 67, 68, 69, > 70, 76, 77, 78, and 112, are considered permanent errors. What are the > meanings of each of these? See /usr/include/sysexits.h > Do each of them generate a different error > message? (they do not seem to map to SMTP error codes, AFAICT). > No, they don't. > 2. It seems that anything that the external program writes to it > STDERR just disappears. Is that right? Is there a way for the external > program to supply text to be used in the error/bounce message? > I don't believe so. - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ courier-users mailing list courier-users@lists.sourceforge.net Unsubscribe: https://lists.sourceforge.net/lists/listinfo/courier-users
Re: [courier-users] courier TLS_PROTOCOL compatibility
Sam Varshavchik wrote: > Gordon Messmer writes: >> The point that I tried to illustrate, after doing the testing, was >> that there's no point to that setting. Nothing can be made better by >> changing it. > > I disagree. One of the reasons -- not the only one, but one of the > factors -- that precipitated this whole discussion is because someone > had made a reasonable argument that, for policy reasons, they wanted > to disable SSL2. Additionally, it is a reasonable position to have a > policy that, for example, allowed only DH-based ciphers. As such, > access to the underlying SSL knobs is needed. Sure, I agree, and we've established that this can be done using TLS_CIPHER_LIST. The TLS_PROTOCOL setting, on the other hand, will only create situations where most connections won't work. When set to TLS1 or SSL3, only an identically configured client will connect. For whatever reason, even courierd using SSL23, which should be compatible in theory, won't connect to an smtpd that's using SSL3 as its protocol setting. That being the case, the setting is useless unless someone wants to establish a tunnel between two courier servers, and those servers aren't going to connect to anything except each other. That's hardly a good enough reason to keep that setting. Even less so since admins can use TLS_CIPHER_LIST to accomplish their goal. TLS_PROTOCOL is just extra cruft that will cause headache for the people who set it, and needlessly adds to the code base. > I'm afraid that most of my daylight hours are spent doing things that > allow me to spend only a few hours a day answering my mail. Those are > the facts of life, that's simply just the way things are. It's not > that I do not appreciate you taking the time to do some research here > -- it is very much appreciated -- it's just that a concise, capsule > summary of your findings would've worked better for me. The summary is: Three days ago, I thought the TLS_PROTOCOL setting was a good idea, and useful toward getting rid of SSL2, and its security deficiencies. After actually looking at the effects of using it, I've reversed that opinion. It's the wrong manner in which to disable SSL2 support. It breaks interoperability with clients that have reasonable SSL configurations. > The only thing that remains unclear is what should be the defaults on > the client side. There are two distinct cases here: protocol-over-SSL, > and STARTTLS-after-protocol, that might require different default > settings. Do you mean "courierd->courieresmtp" client, or imap clients? My first guess would be that they'd work with the same settings: SSL23 method, secure cipher list. I haven't gotten around to that set of tests, though. - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ courier-users mailing list courier-users@lists.sourceforge.net Unsubscribe: https://lists.sourceforge.net/lists/listinfo/courier-users
Re: [courier-users] TLS between courier and MS exchange
matt wrote: > we need to setup TLS between courier (our mail server) and ms exchange > (customers mail server) so that all emails to our customers domain are > encrypted. > As long as the Exchange server advertises STARTTLS support, and you haven't disabled it in courierd, it will be used. You can't, however, make it mandatory in a configuration file without patching Courier: http://phantom.dragonsdawn.net/~gordon/courier-patches/courier.reqtls.patch I expect that it's not a standard feature because even if you set TLS required between two endpoints, you don't necessarily get end-to-end encryption. The next hop may forward your mail elsewhere without TLS in the absence of an extension like Courier's SECURITY=STARTTLS. - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ courier-users mailing list courier-users@lists.sourceforge.net Unsubscribe: https://lists.sourceforge.net/lists/listinfo/courier-users
[courier-users] dot-courier: external program related questions...
Hello all, I have a few questions (which should hopefully be trivial for you) that I could not find the answer for in the documentation, FAQ or Wiki. I am using an external program to pipe to in a /var/courier/etc/ aliasdir/.courier-xyz file. 1. The dot-courier man page says that exit codes 64, 65, 67, 68, 69, 70, 76, 77, 78, and 112, are considered permanent errors. What are the meanings of each of these? Do each of them generate a different error message? (they do not seem to map to SMTP error codes, AFAICT). 2. It seems that anything that the external program writes to it STDERR just disappears. Is that right? Is there a way for the external program to supply text to be used in the error/bounce message? 3. I am trying to use the Perl module Logger::Syslog to log activities in my external program to syslog, but that doesn't seem to work (though it does work when I run the external program script by itself). Any ideas what I may be doing wrong? (I will continue to investigate this). Any thoughts appreciated, --ravi - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ courier-users mailing list courier-users@lists.sourceforge.net Unsubscribe: https://lists.sourceforge.net/lists/listinfo/courier-users
[courier-users] about pythonfilter again
Hello courier-users, I use these modules for pythonfilter # debug noduplicates ratelimit # clamav whitelist_relayclients # auto_whitelist # whitelist_relayclients # whitelist_auth # whitelist_block # whitelist_dnswl # whitelist_spf deliveredto # privateaddr # spfcheck nosuccessdsn # localsenders # greylist # dialback # attachments # quota spamassassin comeagain and after increasing of mail traffic courier said 432 Mail filters temporarily unavailable. and kernel said /kernel: pid 9591 (python), uid 100: exited on signal 11 (core dumped) As I understand problem is in machine resources or maybe you know the way to fix this. Thanks. -- Best regards, Sergio Bortsov mailto:[EMAIL PROTECTED] ISP Neonet 8(098)4491155 8(032)2987593 - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ courier-users mailing list courier-users@lists.sourceforge.net Unsubscribe: https://lists.sourceforge.net/lists/listinfo/courier-users
