value of zero not documented for message_size_limit
Hi, while the documentation for mailbox_size_limit http://www.postfix.org/postconf.5.html#mailbox_size_limit explicitly states [...] or zero (no limit)., the doc for message_size_limit http://www.postfix.org/postconf.5.html#message_size_limit doesn't mention that it's possible to turn off the limit by setting this parameter to zero. Shouldn't that be documented for message_size_limit too? -- Regards mks
Re: OpenSSL 1.0.1g and Ironport SMTP appliances interop issue
Am 11.04.2014 06:53, schrieb Viktor Dukhovni: Note that various vendor SSL updates for Heartbleed may not exhibit the issue. For example, Debian wheezy back-ported just the relevant bug-fix to without back-porting the new padding extension. I also expect similar (fortunate) behaviour on system's with OpenSSL patched by RedHat, and various others confirmed for RedHat, at least i expect the same changeset for RHEL and Fedora https://koji.fedoraproject.org/koji/packageinfo?packageID=109 openssl-1.0.1e-37.fc19.1 / openssl-1.0.1e-37.fc20.1 * Mon Apr 07 2014 Dennis Gilmore den...@ausil.us - 1.0.1e-37.1 - pull in upstream patch for CVE-2014-0160 - removed CHANGES file portion from patch for expediency * Tue Jan 07 2014 Tomáš Mráz tm...@redhat.com 1.0.1e-37 - fix CVE-2013-4353 - Invalid TLS handshake crash - fix CVE-2013-6450 - possible MiTM attack on DTLS1
Re: DKIM, DMARC, Original-Authentication-Results
On Fri 11/Apr/2014 01:40:13 +0200 Scott Kitterman wrote: On April 10, 2014 7:24:54 PM EDT, LuKreme krem...@kreme.com wrote: On 10 Apr 2014, at 17:01 , Viktor Dukhovni postfix-us...@dukhovni.org wrote: On Fri, Apr 11, 2014 at 12:57:54AM +0200, li...@rhsoft.net wrote: Which, IM(ns)HO is what every list should not do. I actually have procmail recipes to untagged subject lines and remove footers on some lists. For a realistic workaround, see John Levine's post list mail with a From: address @yahoo.com is re written to @yahoo.com.INVALID. http://www.ietf.org/mail-archive/web/ietf/current/msg87176.html That said, I thought DKIM ignored everything after the signature delimiter, so if the lists attach the footer *properly* it shouldn't be an issue No, the DKIM spec makes no allowance for signature delimiters. If the body is modified beyond adding removing whitespace (with relaxed canonicalization) the DKIM check fails. That seems like a bug in the implementation of DKIM. It was a deliberate design choice. The signature wouldn't mean much if adding arbitrary text to the message didn't invalidate the signature. It would open the protocol up to replay attacks. There is a virtually unused L tag to embed the length of signed content into the signature, but its use is strongly disrecommended. In fact, HTML allows to append changes which will show up at the beginning of a message. the subject also don't matter in case of signed messages it is a HEADER and headers are added at every hop DKIM also signs message headers. Certain headers, not all of them. Yes, but subject is generally signed (I don't recall seeing a case where it wasn't). Here is an example using both disrecommended options. That way, my DKIM signatures survive through most mailing lists. I don't recommend doing so; it is safer if a mailing list invalidates DKIM signatures, otherwise any recipient could replay those messages, as Scott pointed out. However, the only malfunction I experienced with my unusual setup is that Netease discards my signatures saying DKIM-Signature could not parse or has bad tags/values. (The DKIM spec allows such kind of verifier's policies.) Ale
Re: value of zero not documented for message_size_limit
Markus Sch?nhaber: Hi, while the documentation for mailbox_size_limit http://www.postfix.org/postconf.5.html#mailbox_size_limit explicitly states [...] or zero (no limit)., the doc for message_size_limit http://www.postfix.org/postconf.5.html#message_size_limit doesn't mention that it's possible to turn off the limit by setting this parameter to zero. Shouldn't that be documented for message_size_limit too? The documentation specifies supported behavior. Setting the limit to zero is a really really really bad idea. A non-zero message size limit is the last defense against total mayhem. As it is not documented, the code that allows zero message_size_limit may be removed at any time in the future. Wietse
Re: value of zero not documented for message_size_limit
11.04.2014 13:14, Wietse Venema: Markus Sch?nhaber: Hi, while the documentation for mailbox_size_limit http://www.postfix.org/postconf.5.html#mailbox_size_limit explicitly states [...] or zero (no limit)., the doc for message_size_limit http://www.postfix.org/postconf.5.html#message_size_limit doesn't mention that it's possible to turn off the limit by setting this parameter to zero. Shouldn't that be documented for message_size_limit too? The documentation specifies supported behavior. Setting the limit to zero is a really really really bad idea. A non-zero message size limit is the last defense against total mayhem. As it is not documented, the code that allows zero message_size_limit may be removed at any time in the future. OK, thanks for explaining. -- Regards mks
v4bl.org anyone knows this ?
Hi , anyone knows this rbl ? http://v4bl.org/about.html ... A very extensive list of IPs; which include: » Well known spammer IPs » UBE/UCE abusive IPs » rfc-ignorant IPs » IPs with mismatched DNS and RDNS (FCrDNS failure) » IPs with mismatched rDNS and EHLO/HELO (FCrDNS failure) » IPs of SPAM friendly ESP/HSP/ISP » Obfuscated intermediaries / Alias domains / Disposable domains / Email-only domains » Intermediaries without easily accessible contact information » botnet IPs » and much, much, more... ... sounds very strange to me, this might result in massive problems at some sites, in special checking EHLO/HELO missmatch Best Regards MfG Robert Schetterer -- [*] sys4 AG http://sys4.de, +49 (89) 30 90 46 64 Franziskanerstraße 15, 81669 München Sitz der Gesellschaft: München, Amtsgericht München: HRB 199263 Vorstand: Patrick Ben Koetter, Marc Schiffbauer Aufsichtsratsvorsitzender: Florian Kirstein
smtp client TLS renegotiation
We are encountering problems sending to certain servers are enforcing the renego TLS patch. Our postfix instances do a TLS negotiation but then defer the message with an EHLO handshake error.Should this be working in Postfix v2.9+ ? Or is there something we can set to allow this for some domains. Right now, I have used a tls_policy to not do any TLS with them to send the mail through but was wondering if there is a way to support TLS client-side or if it should be working.Thanks,- Bill Lewis email: william.l.le...@usa.net
Re: smtp client TLS renegotiation
Bill Lewis: We are encountering problems sending to certain servers are enforcing the renego TLS patch. Our postfix instances do a TLS negotiation but then defer the message with an EHLO handshake error.divbr/divdivShould this be working in Postfix v2.9+ ? Or is there something we can set to allow this for some domains. nbsp;Right now, I have used a tls_policy to not do any TLS with them to send the mail through but was wondering if there is a way to support TLS client-side or if it should be working. TLS is implemented by OpenSSL, not Postfix. Wietse
Re: smtp client TLS renegotiation
On Fri, Apr 11, 2014 at 01:30:43PM -0500, Bill Lewis wrote: We are encountering problems sending to certain servers are enforcing the renego TLS patch. What do you mean by renego TLS patch? What specific servers? Our postfix instances do a TLS negotiation but then defer the message with an EHLO handshake error. What version of OpenSSL are you using? When the TLS handshake fails, Postfix generally retries in cleartext, why is the mail deferred? What is your tls policy for these destinations? Logs? Should this be working in Postfix v2.9+? Postfix does not do implement the SSL protocol, that's done by OpenSSL. If you can get openssl s_client -starttls smtp -connect host:25 to work, Postfix will also work (modulo rare cipher-suite list tweaks). If s_client(1) does not work, Postfix is unlikely to have much more luck. Or is there something we can set to allow this for some domains. What is this? Right now, I have used a tls_policy to not do any TLS with them to send the mail through but was wondering if there is a way to support TLS client-side or if it should be working. You're using words I know to construct sentences that I cannot understand. I am afraid you'll need to be much less cryptic. -- Viktor.
Re: value of zero not documented for message_size_limit
On Fri, Apr 11, 2014 at 7:14 AM, Wietse Venema wie...@porcupine.org wrote: Markus Sch?nhaber: Hi, while the documentation for mailbox_size_limit http://www.postfix.org/postconf.5.html#mailbox_size_limit explicitly states [...] or zero (no limit)., the doc for message_size_limit http://www.postfix.org/postconf.5.html#message_size_limit doesn't mention that it's possible to turn off the limit by setting this parameter to zero. Shouldn't that be documented for message_size_limit too? The documentation specifies supported behavior. Setting the limit to zero is a really really really bad idea. A non-zero message size limit is the last defense against total mayhem. Tell that to Apple whose default config sets that value to 0.
Re: value of zero not documented for message_size_limit
Rick Zeman: On Fri, Apr 11, 2014 at 7:14 AM, Wietse Venema wie...@porcupine.org wrote: Markus Sch?nhaber: Hi, while the documentation for mailbox_size_limit http://www.postfix.org/postconf.5.html#mailbox_size_limit explicitly states [...] or zero (no limit)., the doc for message_size_limit http://www.postfix.org/postconf.5.html#message_size_limit doesn't mention that it's possible to turn off the limit by setting this parameter to zero. Shouldn't that be documented for message_size_limit too? The documentation specifies supported behavior. Setting the limit to zero is a really really really bad idea. A non-zero message size limit is the last defense against total mayhem. Tell that to Apple whose default config sets that value to 0. Apple can, and does, make changes to the source code. Wietse
Re: Postfix and TLS 1.2
On Fri, Apr 11, 2014 at 10:32:17PM +0100, Sean Wilson wrote: http://postfix.1071664.n5.nabble.com/Postfix-and-TLS-1-2-td66859.html I am battling to understand why my Postfix server doesn't always use a TLS 1.2 connection with clients that support it. I currently have the latest version of Postfix installed on FreeBSD 10-STABLE and I have OpenSSL version 1.0.1g 7 Apr 2014 installed. This is what happens: When I send an email to someone that uses high grade encryption the log looks as follows: postfix/smtp[2554]: Trusted TLS connection established to mx.domain.com[xxx.xxx.196.175]:25: TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits) All looks good...TLS 1.2 is used and the GCM cipher is used. That's fine mx.domain.com chooses the most preferred cipher offered by the TLS client, i.e. your Postfix SMTP server. When I receive an email from the same client: postfix/smtpd[84316]: Anonymous TLS connection established from mx.domain.com[xxx.xxx.196.175]: TLSv1.1 with cipher ECDHE-RSA-AES256-SHA (256/256) As an SMTP/TLS client, possibly for interoperability reasons, this particular MTA chooses to suppress TLSv1.2. So why is only TLS 1.1 being used? Ask the postmaster of the MTA in question, perhaps they some problems with remote MTAs choking on TLSv1.2 and decided to apply hammer to problem. Also, why isn't the GCM cipher used, isn't this more secure? Perhaps, but not by much, and perhaps it is a TLA plot, GCM is quite fragile in the face of implementation errors and RNG problems. Many think that GCM is not a good choice for software implementations of AEAD ciphers. Do I need to tweak the cipher order to use more secure ciphers and TLS 1.2? No. AES-256-CBC is quite secure enough, the weakest link in protecting your email is probably elsewhere and much weaker than AES-256-CBC. main.cf contains: smtpd_tls_ask_ccert = yes Why? tls_preempt_cipherlist = yes Not recommended. smtpd_tls_mandatory_ciphers = high Fine if all your submission clients are suitable capable. smtpd_tls_ciphers = export Default, but we may at some point change this to medium, so you should probably not set this explicitly. smtp_tls_mandatory_ciphers = $smtpd_tls_mandatory_ciphers smtp_tls_ciphers= $smtpd_tls_ciphers lmtp_tls_mandatory_ciphers = $smtpd_tls_mandatory_ciphers lmtp_tls_ciphers= $smtpd_tls_ciphers Better define some new parameter: site_mandatory_ciphers = high site_ciphers = medium and define the various parameters using those, rather than alias smtp/lmtp values to smtpd values (which won't work if you ever revert the smtpd values to defaults). -- Viktor.
