Re: [courier-users] smtpaccess question
Lindsay Haisley writes: On Wed, 2014-09-24 at 18:33 -0400, Sam Varshavchik wrote: > With a caveat. "Most specific" here means "octet boundary". I should clarify > that in the man page. > > makesmtpaccess uses Net::CIDR to expand out CIDR to even octet boundaries. > So, an entry for 192.168.0.0/22 is going to get replicated as four entries: > 192.168.0.*, 192.168.1.*, 192.168.2.* and 192.168.3.*. So under what circumstances would this differ from the range definition as definded by the CIDR notation? None, that's the point. Using the CIDR notation is equivalent to expanding out the netblocks at the nearest octet boundary. This is the list of entries that goes into the smtpaccess file. So, you can't specify 192.168.0.0/22, and then another entry for 192.168.1.0/24, because the first one is equivalent to specifying 192.168.1.*, and so is the second one. The "more specific" part only applies once you "cross" the octet boundary. This language was from before the CIDR notation could be used in the smtpaccess file. Before the CIDR notation, you could specify: 192.168.0allow,… 192.168.0.1allow,… And so on. The "more specific" part a bit more obvious when looking at this syntax. When CIDR was introduced, nothing actually changed as far as the smtpaccess file goes, except that the CIDR notation results in the entries in the smtpaccess file getting automatically expanded to their component octets. This means that, for example: 192.168.128.0/17 This actually results in 128 actual entries in the smtpaccess file, 192.168.128 through 192.168.255 pgp4bPV8k7zXV.pgp Description: PGP signature -- Meet PCI DSS 3.0 Compliance Requirements with EventLog Analyzer Achieve PCI DSS 3.0 Compliant Status with Out-of-the-box PCI DSS Reports Are you Audit-Ready for PCI DSS 3.0 Compliance? Download White paper Comply to PCI DSS 3.0 Requirement 10 and 11.5 with EventLog Analyzer http://pubads.g.doubleclick.net/gampad/clk?id=154622311&iu=/4140/ostg.clktrk___ courier-users mailing list courier-users@lists.sourceforge.net Unsubscribe: https://lists.sourceforge.net/lists/listinfo/courier-users
Re: [courier-users] smtpaccess question
On Wed, 2014-09-24 at 18:33 -0400, Sam Varshavchik wrote: > With a caveat. "Most specific" here means "octet boundary". I should clarify > that in the man page. > > makesmtpaccess uses Net::CIDR to expand out CIDR to even octet boundaries. > So, an entry for 192.168.0.0/22 is going to get replicated as four entries: > 192.168.0.*, 192.168.1.*, 192.168.2.* and 192.168.3.*. So under what circumstances would this differ from the range definition as definded by the CIDR notation? -- Lindsay Haisley | "UNIX is user-friendly, it just FMP Computer Services | chooses its friends." 512-259-1190 | -- Andreas Bogk http://www.fmp.com| -- Meet PCI DSS 3.0 Compliance Requirements with EventLog Analyzer Achieve PCI DSS 3.0 Compliant Status with Out-of-the-box PCI DSS Reports Are you Audit-Ready for PCI DSS 3.0 Compliance? Download White paper Comply to PCI DSS 3.0 Requirement 10 and 11.5 with EventLog Analyzer http://pubads.g.doubleclick.net/gampad/clk?id=154622311&iu=/4140/ostg.clktrk ___ courier-users mailing list courier-users@lists.sourceforge.net Unsubscribe: https://lists.sourceforge.net/lists/listinfo/courier-users
[courier-users] Bash shell security issue - CVE-2014-6271
There was a security issue disclosed today regarding the bash shell. Fixes to bash should already be available on most platforms, or will be available shortly. My initial analysis is that servers running Courier would only be exploitable using this bash security issue if $HOME/.courier-default or $HOME/.courier- [prefix]-default delivery scripts installed (also the equivalent default scripts in the global aliasdir, as well). Note that couriermlm uses -default files. So, if you are unable to immediately patch your affected version of bash, you should consider temporarily shutting down your mailing lists, and turning off any other - default delivery files you have; until such time as you can update bash. pgpW5URqBcVQ2.pgp Description: PGP signature -- Meet PCI DSS 3.0 Compliance Requirements with EventLog Analyzer Achieve PCI DSS 3.0 Compliant Status with Out-of-the-box PCI DSS Reports Are you Audit-Ready for PCI DSS 3.0 Compliance? Download White paper Comply to PCI DSS 3.0 Requirement 10 and 11.5 with EventLog Analyzer http://pubads.g.doubleclick.net/gampad/clk?id=154622311&iu=/4140/ostg.clktrk___ courier-users mailing list courier-users@lists.sourceforge.net Unsubscribe: https://lists.sourceforge.net/lists/listinfo/courier-users
Re: [courier-users] smtpaccess question
Bowie Bailey writes: On 9/24/2014 4:22 PM, Lindsay Haisley wrote: > What is the order of processing and precedence of address blocks > in /etc/courier/smtpaccess/* ? It looks to me as if a more specific > block, either whitelist or reject, trumps a more general block so that a > reject of 192.168.1.0/24 followed - or preceded - by a whitelist of > 192.168.1.16 would block everything in the larger block EXCEPT the > whitelisted address. Is this the case? If not, what's the rule? > > Is there any precedence of a directive depending on which file it's > found in in /etc/courier/smtpaccess? Do the directives in one file take > precedence over the directives in another? > > I would assume, since the whole directory is processed into a > single .dat file with makesmtpaccess, that the same rule applies > regardless of which file a directive may be found in. The explanations for this are found in the couriertcpd man page. In particular: "couriertcpd always uses the line with the most specific IP address." With a caveat. "Most specific" here means "octet boundary". I should clarify that in the man page. makesmtpaccess uses Net::CIDR to expand out CIDR to even octet boundaries. So, an entry for 192.168.0.0/22 is going to get replicated as four entries: 192.168.0.*, 192.168.1.*, 192.168.2.* and 192.168.3.*. Technically, an explicit entry for 192.168.1.0, for example, will be more specific, but it won't work in this case, because the CIDR notation get expanded (you should get an error, though). pgpM19gMnFPDC.pgp Description: PGP signature -- Meet PCI DSS 3.0 Compliance Requirements with EventLog Analyzer Achieve PCI DSS 3.0 Compliant Status with Out-of-the-box PCI DSS Reports Are you Audit-Ready for PCI DSS 3.0 Compliance? Download White paper Comply to PCI DSS 3.0 Requirement 10 and 11.5 with EventLog Analyzer http://pubads.g.doubleclick.net/gampad/clk?id=154622311&iu=/4140/ostg.clktrk___ courier-users mailing list courier-users@lists.sourceforge.net Unsubscribe: https://lists.sourceforge.net/lists/listinfo/courier-users
Re: [courier-users] courier-unicode
Bowie Bailey writes: Thanks. Now that I know to look for the spec.in file, I can see that the dependency starts with courier-0.73.2. I do not see a dependency listed for courier-authlib, so I guess that answers that question for now. However, for the more general question: If I update courier-unicode on it's own, do I need to rebuild the courier package for it to use the updated unicode package? Only if the binary ABI changes. General answer to a general question, no different than any other inter-package dependency. pgpEO4yLRZq5d.pgp Description: PGP signature -- Meet PCI DSS 3.0 Compliance Requirements with EventLog Analyzer Achieve PCI DSS 3.0 Compliant Status with Out-of-the-box PCI DSS Reports Are you Audit-Ready for PCI DSS 3.0 Compliance? Download White paper Comply to PCI DSS 3.0 Requirement 10 and 11.5 with EventLog Analyzer http://pubads.g.doubleclick.net/gampad/clk?id=154622311&iu=/4140/ostg.clktrk___ courier-users mailing list courier-users@lists.sourceforge.net Unsubscribe: https://lists.sourceforge.net/lists/listinfo/courier-users
Re: [courier-users] Remove Received headers in outgoing authed email?
Jeff Potter writes: Hi List, How do we remove the initial Received header in outgoing email from our servers, or at least mask out the IP address of our sending user? We have an instance of smtpd running specifically for authenticated users (AUTH_REQUIRED=1). I looked through mailing lists; no luck; and I tried TCPDOPTS="-nodnslookup -noidentlookup”, but also no luck. There is no built-in switch to turn this off, but looking around the config files, there might be a way to hack the startup scripts. In the esmtpd configuration file, replace PORT="25" with something like this PORT="25 /usr/bin/env TCPREMOTEIP=127.0.0.1 TCPREMOTEHOST=localhost" This might work in your specific situation only – a dedicated outbound-only server that requires authentication. $PORT is passed to couriertcpd, right before the path to the courieresmtpd executable. This should make the startup script execute env, which will clear out the environment variables before invoking courieresmtpd. pgpqydP2xjrBp.pgp Description: PGP signature -- Meet PCI DSS 3.0 Compliance Requirements with EventLog Analyzer Achieve PCI DSS 3.0 Compliant Status with Out-of-the-box PCI DSS Reports Are you Audit-Ready for PCI DSS 3.0 Compliance? Download White paper Comply to PCI DSS 3.0 Requirement 10 and 11.5 with EventLog Analyzer http://pubads.g.doubleclick.net/gampad/clk?id=154622311&iu=/4140/ostg.clktrk___ courier-users mailing list courier-users@lists.sourceforge.net Unsubscribe: https://lists.sourceforge.net/lists/listinfo/courier-users
Re: [courier-users] new release?
Sam Varshavchik wrote: > I still want to do some more changes to the rpm packaging script, > first. That, pretty much, are the only pending changes I have now; > unless they affect you, you can just take the current snapshot, and go > with it. I found a minor bug (wrong EOL) in courier-imap. Depending on the hassle for you of preparing a release (and if it deserves a release), you may want to wait a bit. (Although I found it when dealing with the CRLF store, it's independent of that - actually, without this bug they should work now) I wanted to provide a patch with the report, but haven't been able to work on that recently. -- Meet PCI DSS 3.0 Compliance Requirements with EventLog Analyzer Achieve PCI DSS 3.0 Compliant Status with Out-of-the-box PCI DSS Reports Are you Audit-Ready for PCI DSS 3.0 Compliance? Download White paper Comply to PCI DSS 3.0 Requirement 10 and 11.5 with EventLog Analyzer http://pubads.g.doubleclick.net/gampad/clk?id=154622311&iu=/4140/ostg.clktrk ___ courier-users mailing list courier-users@lists.sourceforge.net Unsubscribe: https://lists.sourceforge.net/lists/listinfo/courier-users
Re: [courier-users] Remove Received headers in outgoing authed email?
On Wed, 2014-09-24 at 14:28 -0400, Jeff Potter wrote: > How can we remove authed users source IP address? I would think > removing the initial Received from header would be the cleanest way, > but other solutions would work, too. Removing trace headers strikes me as generally a Bad Idea. Redacting the problem IP address would make more sense, IMHO. -- Lindsay Haisley | "UNIX is user-friendly, it just FMP Computer Services | chooses its friends." 512-259-1190 | -- Andreas Bogk http://www.fmp.com| -- Meet PCI DSS 3.0 Compliance Requirements with EventLog Analyzer Achieve PCI DSS 3.0 Compliant Status with Out-of-the-box PCI DSS Reports Are you Audit-Ready for PCI DSS 3.0 Compliance? Download White paper Comply to PCI DSS 3.0 Requirement 10 and 11.5 with EventLog Analyzer http://pubads.g.doubleclick.net/gampad/clk?id=154622311&iu=/4140/ostg.clktrk ___ courier-users mailing list courier-users@lists.sourceforge.net Unsubscribe: https://lists.sourceforge.net/lists/listinfo/courier-users
Re: [courier-users] smtpaccess question
On 9/24/2014 4:22 PM, Lindsay Haisley wrote: > What is the order of processing and precedence of address blocks > in /etc/courier/smtpaccess/* ? It looks to me as if a more specific > block, either whitelist or reject, trumps a more general block so that a > reject of 192.168.1.0/24 followed - or preceded - by a whitelist of > 192.168.1.16 would block everything in the larger block EXCEPT the > whitelisted address. Is this the case? If not, what's the rule? > > Is there any precedence of a directive depending on which file it's > found in in /etc/courier/smtpaccess? Do the directives in one file take > precedence over the directives in another? > > I would assume, since the whole directory is processed into a > single .dat file with makesmtpaccess, that the same rule applies > regardless of which file a directive may be found in. The explanations for this are found in the couriertcpd man page. In particular: "couriertcpd always uses the line with the most specific IP address." -- Bowie -- Meet PCI DSS 3.0 Compliance Requirements with EventLog Analyzer Achieve PCI DSS 3.0 Compliant Status with Out-of-the-box PCI DSS Reports Are you Audit-Ready for PCI DSS 3.0 Compliance? Download White paper Comply to PCI DSS 3.0 Requirement 10 and 11.5 with EventLog Analyzer http://pubads.g.doubleclick.net/gampad/clk?id=154622311&iu=/4140/ostg.clktrk ___ courier-users mailing list courier-users@lists.sourceforge.net Unsubscribe: https://lists.sourceforge.net/lists/listinfo/courier-users
[courier-users] smtpaccess question
What is the order of processing and precedence of address blocks in /etc/courier/smtpaccess/* ? It looks to me as if a more specific block, either whitelist or reject, trumps a more general block so that a reject of 192.168.1.0/24 followed - or preceded - by a whitelist of 192.168.1.16 would block everything in the larger block EXCEPT the whitelisted address. Is this the case? If not, what's the rule? Is there any precedence of a directive depending on which file it's found in in /etc/courier/smtpaccess? Do the directives in one file take precedence over the directives in another? I would assume, since the whole directory is processed into a single .dat file with makesmtpaccess, that the same rule applies regardless of which file a directive may be found in. -- Lindsay Haisley | "UNIX is user-friendly, it just FMP Computer Services | chooses its friends." 512-259-1190 | -- Andreas Bogk http://www.fmp.com| -- Meet PCI DSS 3.0 Compliance Requirements with EventLog Analyzer Achieve PCI DSS 3.0 Compliant Status with Out-of-the-box PCI DSS Reports Are you Audit-Ready for PCI DSS 3.0 Compliance? Download White paper Comply to PCI DSS 3.0 Requirement 10 and 11.5 with EventLog Analyzer http://pubads.g.doubleclick.net/gampad/clk?id=154622311&iu=/4140/ostg.clktrk ___ courier-users mailing list courier-users@lists.sourceforge.net Unsubscribe: https://lists.sourceforge.net/lists/listinfo/courier-users
Re: [courier-users] Remove Received headers in outgoing authed email?
Hi Matus, We have a few high-visibility users for whom leaking their IP address (and thus being able to roughly geo-locate them) isn’t good. We have logs (e.g. /var/log/maillog) that, given a message ID, can be correlated back to an IP address (from the auth part of the login) if that’s ever needed. How can we remove authed users source IP address? I would think removing the initial Received from header would be the cleanest way, but other solutions would work, too. -Jeff On Sep 24, 2014, at 10:05 AM, Matus UHLAR - fantomas wrote: > On 24.09.14 08:37, Jeff Potter wrote: >> How do we remove the initial Received header in outgoing email from our >> servers, or at least mask out the IP address of our sending user? > > why? it's much easier to track problems (both by you and remote admins) if > you don't remove those information. > > -- > Matus UHLAR - fantomas, uh...@fantomas.sk ; http://www.fantomas.sk/ > Warning: I wish NOT to receive e-mail advertising to this address. > Varovanie: na tuto adresu chcem NEDOSTAVAT akukolvek reklamnu postu. > REALITY.SYS corrupted. Press any key to reboot Universe. > > -- > Meet PCI DSS 3.0 Compliance Requirements with EventLog Analyzer > Achieve PCI DSS 3.0 Compliant Status with Out-of-the-box PCI DSS Reports > Are you Audit-Ready for PCI DSS 3.0 Compliance? Download White paper > Comply to PCI DSS 3.0 Requirement 10 and 11.5 with EventLog Analyzer > http://pubads.g.doubleclick.net/gampad/clk?id=154622311&iu=/4140/ostg.clktrk > ___ > courier-users mailing list > courier-users@lists.sourceforge.net > Unsubscribe: https://lists.sourceforge.net/lists/listinfo/courier-users -- Meet PCI DSS 3.0 Compliance Requirements with EventLog Analyzer Achieve PCI DSS 3.0 Compliant Status with Out-of-the-box PCI DSS Reports Are you Audit-Ready for PCI DSS 3.0 Compliance? Download White paper Comply to PCI DSS 3.0 Requirement 10 and 11.5 with EventLog Analyzer http://pubads.g.doubleclick.net/gampad/clk?id=154622311&iu=/4140/ostg.clktrk ___ courier-users mailing list courier-users@lists.sourceforge.net Unsubscribe: https://lists.sourceforge.net/lists/listinfo/courier-users
Re: [courier-users] courier-unicode
On 9/23/2014 7:49 PM, Sam Varshavchik wrote: > Bowie Bailey writes: > >> Is the courier-unicode package actually in use yet? I don't see any >> reference to it as a dependency in the courier or courier-authlib spec >> files and the installation instructions on the website say that it's >> needed as of 0.74. >> >> If it is already in use, do I need to rebuild courier and >> courier-authlib after updating it? > http://sourceforge.net/p/courier/courier.git/ci/master/tree/courier/courier.spec.in > > … > > BuildRequires:courier-unicode-devel > > The dependency is there. Thanks. Now that I know to look for the spec.in file, I can see that the dependency starts with courier-0.73.2. I do not see a dependency listed for courier-authlib, so I guess that answers that question for now. However, for the more general question: If I update courier-unicode on it's own, do I need to rebuild the courier package for it to use the updated unicode package? -- Bowie -- Meet PCI DSS 3.0 Compliance Requirements with EventLog Analyzer Achieve PCI DSS 3.0 Compliant Status with Out-of-the-box PCI DSS Reports Are you Audit-Ready for PCI DSS 3.0 Compliance? Download White paper Comply to PCI DSS 3.0 Requirement 10 and 11.5 with EventLog Analyzer http://pubads.g.doubleclick.net/gampad/clk?id=154622311&iu=/4140/ostg.clktrk ___ courier-users mailing list courier-users@lists.sourceforge.net Unsubscribe: https://lists.sourceforge.net/lists/listinfo/courier-users
Re: [courier-users] Remove Received headers in outgoing authed email?
On 24.09.14 08:37, Jeff Potter wrote: >How do we remove the initial Received header in outgoing email from our > servers, or at least mask out the IP address of our sending user? why? it's much easier to track problems (both by you and remote admins) if you don't remove those information. -- Matus UHLAR - fantomas, uh...@fantomas.sk ; http://www.fantomas.sk/ Warning: I wish NOT to receive e-mail advertising to this address. Varovanie: na tuto adresu chcem NEDOSTAVAT akukolvek reklamnu postu. REALITY.SYS corrupted. Press any key to reboot Universe. -- Meet PCI DSS 3.0 Compliance Requirements with EventLog Analyzer Achieve PCI DSS 3.0 Compliant Status with Out-of-the-box PCI DSS Reports Are you Audit-Ready for PCI DSS 3.0 Compliance? Download White paper Comply to PCI DSS 3.0 Requirement 10 and 11.5 with EventLog Analyzer http://pubads.g.doubleclick.net/gampad/clk?id=154622311&iu=/4140/ostg.clktrk ___ courier-users mailing list courier-users@lists.sourceforge.net Unsubscribe: https://lists.sourceforge.net/lists/listinfo/courier-users
[courier-users] Remove Received headers in outgoing authed email?
Hi List, How do we remove the initial Received header in outgoing email from our servers, or at least mask out the IP address of our sending user? We have an instance of smtpd running specifically for authenticated users (AUTH_REQUIRED=1). I looked through mailing lists; no luck; and I tried TCPDOPTS="-nodnslookup -noidentlookup”, but also no luck. Thanks, Jeff -- Meet PCI DSS 3.0 Compliance Requirements with EventLog Analyzer Achieve PCI DSS 3.0 Compliant Status with Out-of-the-box PCI DSS Reports Are you Audit-Ready for PCI DSS 3.0 Compliance? Download White paper Comply to PCI DSS 3.0 Requirement 10 and 11.5 with EventLog Analyzer http://pubads.g.doubleclick.net/gampad/clk?id=154622311&iu=/4140/ostg.clktrk ___ courier-users mailing list courier-users@lists.sourceforge.net Unsubscribe: https://lists.sourceforge.net/lists/listinfo/courier-users
Re: [courier-users] new release?
Hanno Böck writes: I'd like to get the spf-related fixes and generally a new courier version pushed to Gentoo. I can do this with the snapshot, however I'd prefer a real release. Sam, can you make a new release based on the latest snapshot? I still want to do some more changes to the rpm packaging script, first. That, pretty much, are the only pending changes I have now; unless they affect you, you can just take the current snapshot, and go with it. pgp4XzWNCq70U.pgp Description: PGP signature -- Meet PCI DSS 3.0 Compliance Requirements with EventLog Analyzer Achieve PCI DSS 3.0 Compliant Status with Out-of-the-box PCI DSS Reports Are you Audit-Ready for PCI DSS 3.0 Compliance? Download White paper Comply to PCI DSS 3.0 Requirement 10 and 11.5 with EventLog Analyzer http://pubads.g.doubleclick.net/gampad/clk?id=154622311&iu=/4140/ostg.clktrk___ courier-users mailing list courier-users@lists.sourceforge.net Unsubscribe: https://lists.sourceforge.net/lists/listinfo/courier-users
[courier-users] new release?
I'd like to get the spf-related fixes and generally a new courier version pushed to Gentoo. I can do this with the snapshot, however I'd prefer a real release. Sam, can you make a new release based on the latest snapshot? -- Hanno Böck http://hboeck.de/ mail/jabber: ha...@hboeck.de GPG: BBB51E42 signature.asc Description: PGP signature -- Meet PCI DSS 3.0 Compliance Requirements with EventLog Analyzer Achieve PCI DSS 3.0 Compliant Status with Out-of-the-box PCI DSS Reports Are you Audit-Ready for PCI DSS 3.0 Compliance? Download White paper Comply to PCI DSS 3.0 Requirement 10 and 11.5 with EventLog Analyzer http://pubads.g.doubleclick.net/gampad/clk?id=154622311&iu=/4140/ostg.clktrk___ courier-users mailing list courier-users@lists.sourceforge.net Unsubscribe: https://lists.sourceforge.net/lists/listinfo/courier-users
