Re: TLS smtp_tls_CApath and /etc/ssl/certs
Hi Viktor, thanks for your answer but that does not answer by question. Is the /etc/ssl/certs directory loaded also by default ? I did the test: smtp_tls_CApath = /foo/bar I added/hashed some certs in /foo/bar When postfix connects to a smtp server (tls verify), certificates issued by CAs from /etc/ssl/certs AND from /foo/bar are trusted. Do you confirm this ? Thanks, Jan On Tue, Jun 8, 2010 at 5:56 PM, Victor Duchovni wrote: > On Tue, Jun 08, 2010 at 09:31:46AM +0200, Jan C. wrote: > >> I have my postfix set up as a TLS client to other smtp servers. I >> point smtp_tls_CApath to a directory where I store my own imported >> trusted CAs. My question is whether or not Postfix will also load the >> Root CAs stored in /etc/ssl/certs. If not, does it mean that I have to >> set smtp_tls_CApath to /etc/ssl/certs and store my own root CAs there? > > http://www.postfix.org/TLS_README.html#client_cert_key > > To verify a remote SMTP server certificate, the Postfix SMTP > client needs to trust the certificates of the issuing certification > authorities. These certificates in "pem" format can be stored in > a single $smtp_tls_CAfile or in multiple files, one CA per file > in the $smtp_tls_CApath directory. If you use a directory, don't > forget to create the necessary "hash" links with: > > # $OPENSSL_HOME/bin/c_rehash /path/to/directory > > The $smtp_tls_CAfile contains the CA certificates of one or more > trusted CAs. The file is opened (with root privileges) before Postfix > enters the optional chroot jail and so need not be accessible from > inside the chroot jail. > > Additional trusted CAs can be specified via the $smtp_tls_CApath > directory, in which case the certificates are read (with $mail_owner > privileges) from the files in the directory when the information is > needed. Thus, the $smtp_tls_CApath directory needs to be accessible > inside the optional chroot jail. > > The choice between $smtp_tls_CAfile and $smtp_tls_CApath is a > space/time tradeoff. If there are many trusted CAs, the cost of > preloading them all into memory may not pay off in reduced access > time when the certificate is needed. > > Example: > > /etc/postfix/main.cf: > smtp_tls_CAfile = /etc/postfix/CAcert.pem > smtp_tls_CApath = /etc/postfix/certs > > See also the recent posts about migrating from 0.9.8 CApath to 1.0.0 > CApath where the hash links made by c_rehash are not 0.9.8 compatible > (and vice versa). > > -- > Viktor. >
Re: TLS smtp_tls_CApath and /etc/ssl/certs
Please do not top-post your replies. Thank you. On Wed, Jun 09, 2010 at 10:22:16AM +0200, Jan C. wrote: > thanks for your answer but that does not answer by question. Is the > /etc/ssl/certs directory loaded also by default ? I did the test: Postfix postconf(5) defaults can be shown with the postconf(1) tool: $ /usr/sbin/postconf -d smtp_tls_CApath smtp_tls_CApath = Defaults are also documented as much as possible in the postconf(5) man page; every defined setting has its own hyperlink in the HTML version, as such: postconf.5.html#smtp_tls_CApath > smtp_tls_CApath = /foo/bar > I added/hashed some certs in /foo/bar > > When postfix connects to a smtp server (tls verify), certificates > issued by CAs from /etc/ssl/certs AND from /foo/bar are trusted. Do > you confirm this ? Um, no. By default Postfix is not going to use TLS at all. When activated, by default, no certificate verification is done at all. Consult your distributor's package documentation if they have set different defaults. -- Offlist mail to this address is discarded unless "/dev/rob0" or "not-spam" is in Subject: header
Re: TLS smtp_tls_CApath and /etc/ssl/certs
Hi, > Um, no. By default Postfix is not going to use TLS at all. When > activated, by default, no certificate verification is done at all. > Consult your distributor's package documentation if they have set > different defaults. If I set smtp_tls_CApath to /etc/ssl/certs and then again to something else, it looks like the CAs from /etc/ssl/certs are being all the time loaded: Here is what I did: 1- clean installation of Postfix (2.5.5) on Debian Lenny 2- TLS policy mapping for destination tls.com "verify match=test-tls.com" 3- copy the CA of the test-tls.com to /etc/ssl/certs and run c_rehash 3- leave smtp_tls_CApath empty If I send an email now, it gets deffered (Server certificate not trusted). Until now it makes perfect sense. Now I set: ~ $ postconf -e smtp_tls_CApath=/etc/ssl/certs/ and reload postfix If I send an email, it is correctly sent via TLS. Again, it makes sense. Thing is that now, I set smtp_tls_CApath to something else (empty directory) and the CA is still trusted : ~ $ mkdir -p /foo/bar ~ $ postconf -e smtp_tls_CApath=/foo/bar/ ~ $ postfix reload Postfix log: > tls.com[10.2.87.10]:25: Matched subject_CN=test-tls.com, issuer_CN=Admin Test > TLS .. so how can the certificate be trusted if I point the smtp_tls_CApath to an empty dir ? Still with smtp_tls_CApath pointing to /foo/bar, I delete my CA from /etc/ssl/certs/ and rehash, the email gets again deferred: > relay=tls.com[10.2.87.10]:25, delay=0.11, delays=0.01/0.03/0.07/0, dsn=4.7.5, > status=deferred (Server certificate not trusted) .. so there must be somewhere a reference to /etc/ssl/certs Did I miss something ? Thanks for your help, Jan
Re: unable to telnet localhost 25
On Wed, Jun 9, 2010 at 02:43, J. Roeleveld wrote: > Even though I have considered it myself as well once, I am curious as to why > someone would put a firewall on localhost? Other applications could become compromised by spammy virii that exploited their vulnerabilities and start spewing filth, either by direct connections, or by connections to the local mail server. Of course, running the sendmail command is yet another option.
Re: Setting mime-header checking
Stan Hoeppner: > Noel Jones put forth on 6/8/2010 8:58 AM: > > > and while I've never met anyone named Wietse, I seem to remember seeing > > that name in the postfix copyright statement. His advice might be worth > > paying attention to. > > https://researcher.ibm.com/researcher/view.php?person=us-wietse > http://en.wikipedia.org/wiki/Wietse_Venema > http://www.porcupine.org/wietse/ [etc] Enough. I showed some irritation when he dismissed advice that I spent 15 minutes on, and over-estimated the length of his fuse. Wietse
Re: TLS smtp_tls_CApath and /etc/ssl/certs
Actually, this step is not needed to reproduce it : > Now I set: > ~ $ postconf -e smtp_tls_CApath=/etc/ssl/certs/ > and reload postfix > to sum it up, when smtp_tls_CApath is not empty, CAs from /etc/ssl/certs are trusted regardless the value of smtp_tls_CApath. regards, Jan
trouble with smtp session during before-queue content filtering
Hello, I used to have a old SMTP server, with after-queue content filtering. My new setup involve a before-queue content filter (amavisd). Unfortunately, Amavisd is a little bit strict about the smtp session: it bounces email sent using "MAIL FROM: address" instead of "MAIL FROM:". It's ok for my all my clients but one. It's an appliance, so I cannot change anything about its way to handle SMTP protocol. Here is a debug session: smtp/smtpd[86566]: connect from extron.domain.tld[192.168.42.241] smtp/smtpd[86566]: match_hostaddr: 192.168.42.241 ~? 127.0.0.1 smtp/smtpd[86566]: match_hostaddr: 192.168.42.241 ~? 192.168.0.0/16 smtp/smtpd[86566]: > extron.domain.tld[192.168.42.241]: 220 smtp.domain.tld ESMTP smtp/smtpd[86566]: < extron.domain.tld[192.168.42.241]: HELO extron.domain.tld smtp/smtpd[86566]: > extron.domain.tld[192.168.42.241]: 250 smtp.domain.tld smtp/smtpd[86566]: < extron.domain.tld[192.168.42.241]: MAIL FROM: applia...@domain.tld smtp/smtpd[86566]: > extron.domain.tld[192.168.42.241]: 250 2.1.0 Ok smtp/smtpd[86566]: < extron.domain.tld[192.168.42.241]: RCPT TO: techserv...@domain.tld smtp/smtpd[86566]: check_namadr_access: name extron.domain.tld addr 192.168.42.241 smtp/smtpd[86566]: check_addr_access: 192.168.42.241 smtp/smtpd[86566]: permit_mynetworks: extron.domain.tld 192.168.42.241 smtp/smtpd[86566]: match_hostaddr: 192.168.42.241 ~? 127.0.0.1 smtp/smtpd[86566]: match_hostaddr: 192.168.42.241 ~? 192.168.0.0/16 smtp/smtpd[86566]: > 127.0.0.1:10024: XFORWARD NAME=extron.domain.tld ADDR=192.168.42.241 PORT=2488 HELO=extron.domain.tld PROTO=SMTP SOURCE=LOCAL smtp/smtpd[86566]: > extron.domain.tld[192.168.42.241]: 501 5.5.2 Syntax: MAIL FROM: smtp/smtpd[86566]: match_hostaddr: 192.168.42.241 ~? 127.0.0.1 smtp/smtpd[86566]: match_hostaddr: 192.168.42.241 ~? 192.168.0.0/16 smtp/smtpd[86566]: lost connection after RCPT from extron.domain.tld[192.168.42.241] smtp/smtpd[86566]: disconnect from extron.domain.tld[192.168.42.241] I've read the Postfix documentation, especially this part: > The content filter should accept the same MAIL FROM and RCPT TO command > syntax as the before-filter Postfix SMTP server, and should forward the > commands without modification to the after-filter SMTP server. If the content > filter or after-filter SMTP server does not support all the ESMTP features > that the before-filter Postfix SMTP server supports, then the missing > features must be turned off in the before-filter Postfix SMTP server with the > smtpd_discard_ehlo_keywords parameter. I know the problem is on Amavisd's side. But I'm sure others have been confronted to this issue. Any idea other than patching amavisd? thanks, Patrick PRONIEWSKI -- Administrateur Système - SENTIER - Université Lumière Lyon 2 smime.p7s Description: S/MIME cryptographic signature
Re: TLS smtp_tls_CApath and /etc/ssl/certs
Jan C.:
> Actually, this step is not needed to reproduce it :
> > Now I set:
> > ~ $ postconf -e smtp_tls_CApath=/etc/ssl/certs/
> > and reload postfix
> >
>
> to sum it up, when smtp_tls_CApath is not empty, CAs from
> /etc/ssl/certs are trusted regardless the value of smtp_tls_CApath.
Victor will have to confirm or deny this, but we may have to update
the main code in function tls_set_ca_certificate_info():
if (CAfile || CApath) {
if (!SSL_CTX_load_verify_locations(ctx, CAfile, CApath)) {
msg_info("cannot load Certificate Authority data: "
"disabling TLS support");
tls_print_errors();
return (-1);
}
+ } else {
if (!SSL_CTX_set_default_verify_paths(ctx)) {
msg_info("cannot set certificate verification paths: "
"disabling TLS support");
tls_print_errors();
return (-1);
}
}
Unfortunately OpenSSL has no documentation for the
SSL_CTX_set_default_verify_paths() function, so it is hard to be
sure that the function is used in a correct manner.
The change above is based on a patch for the s_client program:
http://rt.openssl.org/Ticket/Display.html?id=2203&user=guest&pass=guest
Wietse
Re: trouble with smtp session during before-queue content filtering
Proniewski Patrick: > Hello, > > I used to have a old SMTP server, with after-queue content filtering. > My new setup involve a before-queue content filter (amavisd). > Unfortunately, Amavisd is a little bit strict about the smtp > session: it bounces email sent using "MAIL FROM: address" instead > of "MAIL FROM:". > It's ok for my all my clients but one. It's an appliance, so I > cannot change anything about its way to handle SMTP protocol. Besides making this configurable for Amavisd-new, the other option is to use the Postfix 2.7 smtpd_command_filter feature to replace the RCPT TO command very carefully. If the applicance sends mail to only one address, be sure to modify only that RCPT TO command and nothing else. Wietse smtpd_command_filter (default: empty) A mechanism to transform commands from remote SMTP clients. This is a last-resort tool to work around client commands that break inter-oper- ability with the Postfix SMTP server. Other uses involve fault injec- tion to test Postfix's handling of invalid commands. Specify the name of a "type:table" lookup table. The search string is the SMTP command as received from the remote SMTP client, except that initial whitespace and the trailing are removed. The result value is executed by the Postfix SMTP server. There is no need to use smtpd_command_filter for the following cases: o Use "resolve_numeric_domain = yes" to accept "u...@ipaddress". o Postfix already accepts the correct form "u...@[ipaddress]". Use virtual_alias_maps or canonical_maps to translate these into domain names if necessary. o Use "strict_rfc821_envelopes = no" to accept "RCPT TO:>". Postfix will ignore the "User Name" part and deliver to the address. Examples of problems that can be solved with the smtpd_command_filter feature: /etc/postfix/main.cf: smtpd_command_filter = pcre:/etc/postfix/command_filter /etc/postfix/command_filter: # Work around clients that send malformed HELO commands. /^HELO\s*$/ HELO domain.invalid # Work around clients that send empty lines. /^\s*$/ NOOP # Work around clients that send RCPT TO:<'u...@domain'>. # WARNING: do not lose the parameters that follow the address. /^RCPT\s+TO:\s*<'([^[:space:]]+)'>(.*)/ RCPT TO:<$1>$2 # Bounce-never mail sink. Use notify_classes=bounce,resource,software # to send bounced mail to the postmaster (with message body removed). /^(RCPT\s+TO:.*?)\bNOTIFY=\S+\b(.*)/ $1 NOTIFY=NEVER $2 /^(RCPT\s+TO:.*)/$1 NOTIFY=NEVER This feature is available in Postfix 2.7.
Re: TLS smtp_tls_CApath and /etc/ssl/certs
On Wed, Jun 09, 2010 at 11:25:50AM -0400, Wietse Venema wrote:
> > to sum it up, when smtp_tls_CApath is not empty, CAs from
> > /etc/ssl/certs are trusted regardless the value of smtp_tls_CApath.
This is done primarily by OpenSSL, but as Wietse observes:
> Victor will have to confirm or deny this, but we may have to update
> the main code in function tls_set_ca_certificate_info():
>
> if (CAfile || CApath) {
> if (!SSL_CTX_load_verify_locations(ctx, CAfile, CApath)) {
> msg_info("cannot load Certificate Authority data: "
> "disabling TLS support");
> tls_print_errors();
> return (-1);
> }
> + } else {
> if (!SSL_CTX_set_default_verify_paths(ctx)) {
> msg_info("cannot set certificate verification paths: "
> "disabling TLS support");
> tls_print_errors();
> return (-1);
> }
> }
We could make this change, but it would be an incompatibility with past
behaviour. This code dates back to the original TLS patch for Postfix
releases prior to 2.1, and augments the default system CA paths, instead
of replacing them.
I guess our documentation has never promised the use of system CAs when
CApath or CAfile are set, failing to override the system settings is
counter-intuitive, so I can support this change. We'll also have to
document the semantics of "CAfile == CApath == ".
> Unfortunately OpenSSL has no documentation for the
> SSL_CTX_set_default_verify_paths() function, so it is hard to be
> sure that the function is used in a correct manner.
The function is used correctly, and sadly a large part of the OpenSSL
API that is not internal, and ought to be documented, is not.
> The change above is based on a patch for the s_client program:
> http://rt.openssl.org/Ticket/Display.html?id=2203&user=guest&pass=guest
This largely explains how Postfix came to have the code it does. Since
OpenSSL is both complex and incompletely documented, many OpenSSL client
applications are cargo-cult copies of example code in the OpenSSL apps/
directory, with SSL apps typically borrowing code snippets from s_client
and s_server.
The patch whose URL is above has not yet been adopted into OpenSSL, the
1.0.0a release still has the original code:
if ((!SSL_CTX_load_verify_locations(ctx,CAfile,CApath)) ||
(!SSL_CTX_set_default_verify_paths(ctx)))
{
/* BIO_printf(bio_err,"error setting default verify locations\n"); */
ERR_print_errors(bio_err);
/* goto end; */
}
--
Viktor.
Re: TLS smtp_tls_CApath and /etc/ssl/certs
Hello, ok then t least I know what's the origin of the behavior I had. On Wed, Jun 9, 2010 at 6:12 PM, Victor Duchovni wrote: > I guess our documentation has never promised the use of system CAs when > CApath or CAfile are set, failing to override the system settings is > counter-intuitive, so I can support this change. We'll also have to > document the semantics of "CAfile == CApath == ". so what I should do is to suppose that only the certs from smtp_tls_CApath are trusted and that's all. If I need the system CAs, I should copy them to my smtp_tls_CApath directory .. correct ? Thanks for your support, Jan
Re: TLS smtp_tls_CApath and /etc/ssl/certs
On Wed, Jun 09, 2010 at 06:30:59PM +0200, Jan C. wrote: > Hello, > ok then t least I know what's the origin of the behavior I had. > > On Wed, Jun 9, 2010 at 6:12 PM, Victor Duchovni > wrote: > > I guess our documentation has never promised the use of system CAs when > > CApath or CAfile are set, failing to override the system settings is > > counter-intuitive, so I can support this change. We'll also have to > > document the semantics of "CAfile == CApath == ". > > so what I should do is to suppose that only the certs from > smtp_tls_CApath are trusted and that's all. If I need the system CAs, > I should copy them to my smtp_tls_CApath directory .. correct ? Probably, although I don't think we've reached a final decision yet... My preference is to not trust some random list of CAs that came with the O/S OpenSSL package when the user specifies an explicit CAfile/CApath, but this would be an incompatible change. In my case, the OpenSSL package I use is built by me, and has an empty default list of trusted CAs, so I never notice the extra default certs. -- Viktor.
Re: TLS smtp_tls_CApath and /etc/ssl/certs
On Wed, Jun 9, 2010 at 6:35 PM, Victor Duchovni wrote: > Probably, although I don't think we've reached a final decision yet... > My preference is to not trust some random list of CAs that came with the > O/S OpenSSL package when the user specifies an explicit CAfile/CApath, > but this would be an incompatible change. > > In my case, the OpenSSL package I use is built by me, and has an empty > default list of trusted CAs, so I never notice the extra default certs. > ok, could you please point me to the place where one can set those paths while building OpenSSL ? Jan
Re: TLS smtp_tls_CApath and /etc/ssl/certs
On Wed, Jun 09, 2010 at 06:39:26PM +0200, Jan C. wrote: > On Wed, Jun 9, 2010 at 6:35 PM, Victor Duchovni > wrote: > > Probably, although I don't think we've reached a final decision yet... > > My preference is to not trust some random list of CAs that came with the > > O/S OpenSSL package when the user specifies an explicit CAfile/CApath, > > but this would be an incompatible change. > > > > In my case, the OpenSSL package I use is built by me, and has an empty > > default list of trusted CAs, so I never notice the extra default certs. > > > > ok, could you please point me to the place where one can set those > paths while building OpenSSL ? You are too lazy to run "Configure --help"? OK, though it is off-topic here: Usage: Configure [no- ...] [enable- ...] [experimental- ...] [-Dxxx] [-lxxx] [-Lxxx] [-fxxx] [-Kxxx] [no-hw-xxx|no-hw] [[no-]threads] [[no-]shared] [[no-]zlib|zlib-dynamic] [no-asm] [no-dso] [no-krb5] [386] --> [--prefix=DIR] --> [--openssldir=OPENSSLDIR] [--with-xxx[=vvv]] [--test-sanity] os/compiler[:flags] If only specify "prefix" the cert directory is $prefix/ssl, otherwise it is $openssldir, in which OpenSSL itself does not place any default certificates, that's done by vendor package maintainers. OpenSSL itself installs just: .../ssl/ .../ssl/openssl.cnf .../ssl/private/ .../ssl/certs/ .../ssl/misc/ .../ssl/misc/CA.pl .../ssl/misc/CA.sh .../ssl/misc/c_hash .../ssl/misc/c_info .../ssl/misc/c_issuer .../ssl/misc/c_name .../ssl/misc/tsget -- Viktor.
Re: TLS smtp_tls_CApath and /etc/ssl/certs
Victor Duchovni:
> On Wed, Jun 09, 2010 at 11:25:50AM -0400, Wietse Venema wrote:
>
> > > to sum it up, when smtp_tls_CApath is not empty, CAs from
> > > /etc/ssl/certs are trusted regardless the value of smtp_tls_CApath.
>
> This is done primarily by OpenSSL, but as Wietse observes:
>
> > Victor will have to confirm or deny this, but we may have to update
> > the main code in function tls_set_ca_certificate_info():
> >
> > if (CAfile || CApath) {
> > if (!SSL_CTX_load_verify_locations(ctx, CAfile, CApath)) {
> > msg_info("cannot load Certificate Authority data: "
> > "disabling TLS support");
> > tls_print_errors();
> > return (-1);
> > }
> > + } else {
> > if (!SSL_CTX_set_default_verify_paths(ctx)) {
> > msg_info("cannot set certificate verification paths: "
> > "disabling TLS support");
> > tls_print_errors();
> > return (-1);
> > }
> > }
>
> We could make this change, but it would be an incompatibility with past
> behaviour. This code dates back to the original TLS patch for Postfix
> releases prior to 2.1, and augments the default system CA paths, instead
> of replacing them.
>
> I guess our documentation has never promised the use of system CAs when
> CApath or CAfile are set, failing to override the system settings is
> counter-intuitive, so I can support this change. We'll also have to
> document the semantics of "CAfile == CApath == ".
The empty setting would correspond with the default system-supplied
CA certificates.
There is at least one Postfix feature that relies on the ability
to override the default system-supplied CA certificates:
permit_tls_all_clientcerts
Permit the request when the remote SMTP client certificate is
verified successfully. This option must be used only if a spe-
cial CA issues the certificates and only this CA is listed as
trusted CA, otherwise all clients with a recognized certificate
would be allowed to relay. This feature is available with Post-
fix version 2.2.
It would seem then that permit_tls_all_clientcerts is broken.
What else would be broken by the current practice of always including
the default CA certificates? If there is nothing else, then most
sites would not be affected, but a lot of sites could be at risk of
breaking when we change the CAfile/CApath behavior.
Therefore it would be desirable to provide a compatibility switch
that is "incompatible" for Postfix 2.8 and "compatible" for the
earlier releases.
Wietse
Yahoo disconnecting at end of data on large messages.
One of our users sent a large (about 10MB) e-mail to Yahoo. Yahoo has not been accepting it, they don't give a reason, they just disconnect after getting the whole message: Jun 9 13:20:50 hobbes postfix/smtp[7398]: 02EB432E022: lost connection with e.mx.mail.yahoo.com[67.195.168.230] while sending end of data -- message may be sent more than once Small messages make it through without a problem, and sending the same message from a Gmail account works. I've tried messing with MTU size (down to 950 from 1500), various sysctl settings, DKIM signing and probably a few things I'm forgetting about: to no avail. The best I can find is this post: http://article.gmane.org/gmane.mail.postfix.user/208435 But there's no resolution. Can anyone suggest other things to try or other information to gather so I can figure out what's wrong with my setup or what's wrong with Yahoo (and how to work around it)? Thanks. -- Philippe Chaintreuil
Re: TLS smtp_tls_CApath and /etc/ssl/certs
On Wed, Jun 09, 2010 at 01:34:53PM -0400, Wietse Venema wrote: > > I guess our documentation has never promised the use of system CAs when > > CApath or CAfile are set, failing to override the system settings is > > counter-intuitive, so I can support this change. We'll also have to > > document the semantics of "CAfile == CApath == ". > > The empty setting would correspond with the default system-supplied > CA certificates. > > There is at least one Postfix feature that relies on the ability > to override the default system-supplied CA certificates: > >permit_tls_all_clientcerts > Permit the request when the remote SMTP client certificate is > verified successfully. This option must be used only if a spe- > cial CA issues the certificates and only this CA is listed as > trusted CA, otherwise all clients with a recognized certificate > would be allowed to relay. This feature is available with Post- > fix version 2.2. Good point, oops! This too pre-dates Postfix 2.2, but it is rather unsafe when the default system CA list includes all the usual suspects. > It would seem then that permit_tls_all_clientcerts is broken. Yes, for Postfix distributions where the vendor helpfully populates the OpenSSL "ssl/certs/" directory. > What else would be broken by the current practice of always including > the default CA certificates? If there is nothing else, then most > sites would not be affected, but a lot of sites could be at risk of > breaking when we change the CAfile/CApath behavior. Trusting unwanted CAs on the server side means: 1. The "Received:" header (Client CN, ... verified OK) could be misleading. 2. The "smtpd_tls_req_ccert" feature may be more permissive than desired. 3. As you observed "permit_tls_all_clientcerts" is unsafe. 4. Policy service requests may pass client CNs that are not intended to be trusted. 5. Milters may process the client subject and issuer CN. On the client side, we only use server certificates for destinations with a "verify" or "secure" policy, so here the risk is MITM if one of the public CAs issues certs that one has good cause to not trust. > Therefore it would be desirable to provide a compatibility switch > that is "incompatible" for Postfix 2.8 and "compatible" for the > earlier releases. Works for me. And of course a new warning in the "permit_tls_all_clientcerts" postconf(5) entry. -- Viktor.
Postfix chroot on RHEL5....
Hi: I've a question about setting up postfix in a chroot on a Linux RHEL5 setup. I'm using the RedHat package of postfix (Version 2.3.3) which was installed with the RedHat install. Everything is working fine, but now I want to chroot it. On the Postfix website, it says: "In order to enable chroot operation, edit the file /etc/postfix/master.cf , and follow instructions in the file " There aren't any instructions in there. I went through master.cf anyway, and converted the n's to y's (in the chroot column), then issued the "postfix reload" command. And obviously, now I have problems. So, I have a couple of questions: 1. Can anyone point me to documentation for my distro, on how to chroot postfix? 2. If SELINUX is running, is it even necessary to chroot postfix? Note: This postfix system is only acting as a smtp gateway Regards, Fred Schnittke
Re: Postfix chroot on RHEL5....
2010/6/9 : > Hi: > > I've a question about setting up postfix in a chroot on a Linux RHEL5 setup. > I'm using the RedHat package of postfix (Version 2.3.3) which was installed > with the RedHat install. Everything is working fine, but now I want to > chroot it. On the Postfix website, it says: > > "In order to enable chroot operation, edit the file /etc/postfix/master.cf, > and follow instructions in the file " > > There aren't any instructions in there. > > I went through master.cf anyway, and converted the n's to y's (in the chroot > column), then issued the "postfix reload" command. And obviously, now I have > problems. > > So, I have a couple of questions: > > 1. Can anyone point me to documentation for my distro, on how to chroot > postfix? try google > 2. If SELINUX is running, is it even necessary to chroot postfix? > > Note: This postfix system is only acting as a smtp gateway Well, postfix is safe without chroot. -- Eero
Re: Yahoo disconnecting at end of data on large messages.
Le 09/06/2010 19:35, Philippe Chaintreuil a écrit : > One of our users sent a large (about 10MB) e-mail to Yahoo. Yahoo has > not been accepting it, they don't give a reason, they just disconnect > after getting the whole message: > > > Jun 9 13:20:50 hobbes postfix/smtp[7398]: 02EB432E022: lost connection > with e.mx.mail.yahoo.com[67.195.168.230] while sending end of data -- > message may be sent more than once > > > Small messages make it through without a problem, and sending the same > message from a Gmail account works. > > I've tried messing with MTU size (down to 950 from 1500), various > sysctl settings, DKIM signing and probably a few things I'm forgetting > about: to no avail. > > The best I can find is this post: > > http://article.gmane.org/gmane.mail.postfix.user/208435 > > But there's no resolution. > > Alas, I never received any follow-up. I sense it could be a time-out due to DSL - but I still don't understand why it only does it with Yahoo and with no-one else. Warm regards, Olivier -- Olivier MJ Crépin-Leblond, PhD http://www.gih.com/ocl.html
Re: Yahoo disconnecting at end of data on large messages.
Philippe Chaintreuil: > One of our users sent a large (about 10MB) e-mail to Yahoo. Yahoo has > not been accepting it, they don't give a reason, they just disconnect > after getting the whole message: > > > Jun 9 13:20:50 hobbes postfix/smtp[7398]: 02EB432E022: lost connection > with e.mx.mail.yahoo.com[67.195.168.230] while sending end of data -- > message may be sent more than once > > > Small messages make it through without a problem, and sending the same > message from a Gmail account works. Instead of tweaking, spend the effort to become whitelisted. Wietse
Re: Yahoo disconnecting at end of data on large messages.
On Wed, 9 Jun 2010, Olivier MJ Crepin-Leblond wrote: Le 09/06/2010 19:35, Philippe Chaintreuil a ?crit : One of our users sent a large (about 10MB) e-mail to Yahoo. Yahoo has not been accepting it, they don't give a reason, they just disconnect after getting the whole message: Jun 9 13:20:50 hobbes postfix/smtp[7398]: 02EB432E022: lost connection with e.mx.mail.yahoo.com[67.195.168.230] while sending end of data -- message may be sent more than once Small messages make it through without a problem, and sending the same message from a Gmail account works. I've tried messing with MTU size (down to 950 from 1500), various sysctl settings, DKIM signing and probably a few things I'm forgetting about: to no avail. The best I can find is this post: http://article.gmane.org/gmane.mail.postfix.user/208435 But there's no resolution. Alas, I never received any follow-up. I sense it could be a time-out due to DSL - but I still don't understand why it only does it with Yahoo and with no-one else. Because it's Yahoo. Yahoo's defers mail for all sort of unfathomable reasons. As Wieste just posted, the OP should jump through Yahoo's hoops to become white-listed. -- Larry Stone lston...@stonejongleux.com
Re: Yahoo disconnecting at end of data on large messages.
On Wed, Jun 09, 2010 at 01:35:03PM -0400, Philippe Chaintreuil wrote: > One of our users sent a large (about 10MB) e-mail to Yahoo. Yahoo has > not been accepting it, they don't give a reason, they just disconnect > after getting the whole message: > > > Jun 9 13:20:50 hobbes postfix/smtp[7398]: 02EB432E022: lost connection > with e.mx.mail.yahoo.com[67.195.168.230] while sending end of data -- > message may be sent more than once > Make sure you don't have window-scaling enabled on your MTA, and that path MTU discovery works through your firewall. If that does not solve it, see other suggestions in thread. -- Viktor.
Re: trouble with smtp session during before-queue content filtering
On 6/9/2010 10:11 AM, Proniewski Patrick wrote: Hello, I used to have a old SMTP server, with after-queue content filtering. My new setup involve a before-queue content filter (amavisd). Unfortunately, Amavisd is a little bit strict about the smtp session: it bounces email sent using "MAIL FROM: address" instead of "MAIL FROM:". It's ok for my all my clients but one. It's an appliance, so I cannot change anything about its way to handle SMTP protocol. Here is a debug session: smtp/smtpd[86566]: connect from extron.domain.tld[192.168.42.241] smtp/smtpd[86566]: match_hostaddr: 192.168.42.241 ~? 127.0.0.1 smtp/smtpd[86566]: match_hostaddr: 192.168.42.241 ~? 192.168.0.0/16 smtp/smtpd[86566]:> extron.domain.tld[192.168.42.241]: 220 smtp.domain.tld ESMTP smtp/smtpd[86566]:< extron.domain.tld[192.168.42.241]: HELO extron.domain.tld smtp/smtpd[86566]:> extron.domain.tld[192.168.42.241]: 250 smtp.domain.tld smtp/smtpd[86566]:< extron.domain.tld[192.168.42.241]: MAIL FROM: applia...@domain.tld smtp/smtpd[86566]:> extron.domain.tld[192.168.42.241]: 250 2.1.0 Ok smtp/smtpd[86566]:< extron.domain.tld[192.168.42.241]: RCPT TO: techserv...@domain.tld smtp/smtpd[86566]: check_namadr_access: name extron.domain.tld addr 192.168.42.241 smtp/smtpd[86566]: check_addr_access: 192.168.42.241 smtp/smtpd[86566]: permit_mynetworks: extron.domain.tld 192.168.42.241 smtp/smtpd[86566]: match_hostaddr: 192.168.42.241 ~? 127.0.0.1 smtp/smtpd[86566]: match_hostaddr: 192.168.42.241 ~? 192.168.0.0/16 smtp/smtpd[86566]:> 127.0.0.1:10024: XFORWARD NAME=extron.domain.tld ADDR=192.168.42.241 PORT=2488 HELO=extron.domain.tld PROTO=SMTP SOURCE=LOCAL smtp/smtpd[86566]:> extron.domain.tld[192.168.42.241]: 501 5.5.2 Syntax: MAIL FROM: smtp/smtpd[86566]: match_hostaddr: 192.168.42.241 ~? 127.0.0.1 smtp/smtpd[86566]: match_hostaddr: 192.168.42.241 ~? 192.168.0.0/16 smtp/smtpd[86566]: lost connection after RCPT from extron.domain.tld[192.168.42.241] smtp/smtpd[86566]: disconnect from extron.domain.tld[192.168.42.241] I've read the Postfix documentation, especially this part: The content filter should accept the same MAIL FROM and RCPT TO command syntax as the before-filter Postfix SMTP server, and should forward the commands without modification to the after-filter SMTP server. If the content filter or after-filter SMTP server does not support all the ESMTP features that the before-filter Postfix SMTP server supports, then the missing features must be turned off in the before-filter Postfix SMTP server with the smtpd_discard_ehlo_keywords parameter. I know the problem is on Amavisd's side. But I'm sure others have been confronted to this issue. Any idea other than patching amavisd? thanks, Patrick PRONIEWSKI For problems with amavisd-new, better to ask on the amavis-users list. I don't think this is configurable in amavisd-new, in which case the easiest solution is to redirect the problem client to an unfiltered postfix listener. Either have the client connect to a different IP:port, or use firewall redirect rules. -- Noel Jones
Re: Yahoo disconnecting at end of data on large messages.
On 6/9/10 5:34 PM, Victor Duchovni wrote: > Make sure you don't have window-scaling enabled on your MTA, and that > path MTU discovery works through your firewall. If that does not solve it, > see other suggestions in thread. I turned off my firewall (iptables) and the issue still occurs. I also tried turning off MTU discovery while the MTU was set low (950). I also expanded the keep-alive time with no love, same goes for disabling window-scaling. -- Philippe Chaintreuil
Re: TLS smtp_tls_CApath and /etc/ssl/certs
Victor Duchovni: > I guess our documentation has never promised the use of system CAs when > CApath or CAfile are set, failing to override the system settings is > counter-intuitive, so I can support this change. We'll also have to > document the semantics of "CAfile == CApath == ". Why do we have to document or change Postfix default behavior? Default Postfix behavior (empty CAfile and CApath) is a NOOP. Postfix calls neither SSL_CTX_load_verify_locations() nor SSL_CTX_set_default_verify_paths(). First, I don't see why we should change Postfix default behavior: the problem is with non-default settings. Second, I don't see how we could document existing Postfix default behavior (empty CAfile and CApath), when that behavior is not defined by the OpenSSL API. OpenSSL source code does not count as a definition, nor do words from OpenSSL programmers or code examples. They can change program behavior because they are not bound by the contract of an API. Wietse
postcat, multi-instance setup
I'm most likely doing it wrong: $ postmulti -i postfix-out -x mailq -Queue ID- --Size-- Arrival Time -Sender/Recipient--- 1BCBD1DF86 2622 Mon Jun 7 03:02:34 boskop-svn-bounces+trac=trac.incertum@lists.incertum.net (connect to trac.incertum.net[85.214.20.182]:25: Connection refused) t...@trac.incertum.net -- 3 Kbytes in 1 Request. $ postmulti -i postfix-out -x postcat -q 1BCBD1DF86 postcat: fatal: open queue file 1BCBD1DF86: No such file or directory Apart from my obvious fault (wrong mail routing which led to the mail's deferral) - how do I actually access the contents of this file? Stefan
Re: postcat, multi-instance setup
* Stefan Foerster :
> I'm most likely doing it wrong:
>
> $ postmulti -i postfix-out -x mailq
> -Queue ID- --Size-- Arrival Time -Sender/Recipient---
> 1BCBD1DF86 2622 Mon Jun 7 03:02:34
> boskop-svn-bounces+trac=trac.incertum@lists.incertum.net
> (connect to trac.incertum.net[85.214.20.182]:25: Connection refused)
> t...@trac.incertum.net
>
> -- 3 Kbytes in 1 Request.
> $ postmulti -i postfix-out -x postcat -q 1BCBD1DF86
> postcat: fatal: open queue file 1BCBD1DF86: No such file or directory
>
> Apart from my obvious fault (wrong mail routing which led to the
> mail's deferral) - how do I actually access the contents of this
> file?
Since somebody is going to ask this question: 2.7.
$ postmulti -i postfix-out -x postconf -n
alias_database =
alias_maps =
authorized_submit_users = root
config_directory = /etc/postfix-out
data_directory = /var/lib/postfix-out
local_header_rewrite_clients =
local_recipient_maps =
local_transport = error:5.1.1 Mailbox unavailable
master_service_disable =
multi_instance_enable = yes
multi_instance_group = mta
multi_instance_name = postfix-out
mydestination =
mydomain = incertum.net
myhostname = edge.kvm.incertum.net
mynetworks = 127.0.0.0/8, 192.168.122.0/24, 85.214.20.182/32,
85.214.107.53/32
myorigin = $mydomain
parent_domain_matches_subdomains =
queue_directory = /var/spool/postfix-out
receive_override_options = no_unknown_recipient_checks
recipient_delimiter = +
relay_destination_concurrency_limit = 4
smtp_helo_name = mail.incertum.net
smtp_tls_CAfile = /etc/ssl/certs/ca-certificates.crt
smtp_tls_loglevel = 1
smtp_tls_security_level = may
smtp_tls_session_cache_database = btree:${data_directory}/smtp_scache
smtp_tls_session_cache_timeout = 24h
smtpd_authorized_xforward_hosts = $mynetworks
smtpd_client_connection_count_limit = 0
smtpd_client_event_limit_exceptions = $mynetworks
smtpd_recipient_restrictions = permit_mynetworks, reject
smtpd_timeout = 1200s
transport_maps = cdb:/etc/postfix/transport_maps
Stefan
