Postfix TLS: SSL3_GET_CLIENT_HELLO:no shared cipher

2011-09-05 Thread whizz 
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Hi,

I have a postfix set-up with TLS activated.
Outlook 2010 and Thunderbird can send any e-mail just fine.

Openssl -connect  -starttls smtp returned no error
either.

The thing is I'm trying to check my SSL configuration using this
tool:
http://www.networking4all.com/en/support/tools/site+check/report/

and while it can validate mt certificate just fine, it says that it
can't establish a secure connection.

I inspected my maillog and this is what I get:

mailog:
Aug 31 21:01:42 johndoe postfix/smtpd[10223]: connect from
s097.networking4all.com[213.249.64.242]
Aug 31 21:01:42 johndoe postfix/smtpd[10223]: NOQUEUE: reject:
CONNECT from s097.networking4all.com[213.249.64.242]: 554 5.7.1
: Client host rejected:
Access denied; proto=SMTP
Aug 31 21:01:43 johndoe postfix/smtpd[10223]: disconnect from
s097.networking4all.com[213.249.64.242]
Aug 31 21:01:43 johndoe postfix/smtpd[10223]: connect from
s097.networking4all.com[213.249.64.242]
Aug 31 21:01:53 johndoe postfix/smtpd[10223]: SSL_accept error from
s097.networking4all.com[213.249.64.242]: -1
Aug 31 21:01:53 johndoe postfix/smtpd[10223]: lost connection after
CONNECT from s097.networking4all.com[213.249.64.242]
Aug 31 21:01:53 johndoe postfix/smtpd[10223]: disconnect from
s097.networking4all.com[213.249.64.242]
Aug 31 21:01:53 johndoe postfix/smtpd[10223]: connect from
s097.networking4all.com[213.249.64.242]
Aug 31 21:01:53 johndoe postfix/smtpd[10223]: NOQUEUE: reject:
CONNECT from s097.networking4all.com[213.249.64.242]: 554 5.7.1
: Client host rejected:
Access denied; proto=SMTP
Aug 31 21:01:53 johndoe postfix/smtpd[10223]: disconnect from
s097.networking4all.com[213.249.64.242]
Aug 31 21:01:54 johndoe postfix/smtpd[10223]: connect from
s097.networking4all.com[213.249.64.242]
Aug 31 21:01:55 johndoe postfix/smtpd[10223]: NOQUEUE: reject:
CONNECT from s097.networking4all.com[213.249.64.242]: 554 5.7.1
: Client host rejected:
Access denied; proto=SMTP
Aug 31 21:01:55 johndoe postfix/smtpd[10223]: disconnect from
s097.networking4all.com[213.249.64.242]
Aug 31 21:01:55 johndoe postfix/smtpd[10223]: connect from
s097.networking4all.com[213.249.64.242]
Aug 31 21:01:55 johndoe postfix/smtpd[10223]: SSL_accept error from
s097.networking4all.com[213.249.64.242]: -1
Aug 31 21:01:55 johndoe postfix/smtpd[10223]: warning: TLS library
problem: 10223:error:1408A0C1:SSL routines:SSL3_GET_CLIENT_HELLO:no
shared cipher:s3_srvr.c:1221:
Aug 31 21:01:55 johndoe postfix/smtpd[10223]: lost connection after
CONNECT from s097.networking4all.com[213.249.64.242]
Aug 31 21:01:55 johndoe postfix/smtpd[10223]: disconnect from
s097.networking4all.com[213.249.64.242]



So I added
smtpd_tls_loglevel = 2
smtpd_tls_received_header = yes

This is what I get in the maillog
Aug 31 21:38:01 johndoe postfix/smtpd[16200]: initializing the
server-side TLS engine
Aug 31 21:38:01 johndoe postfix/smtpd[16200]: connect from
s097.networking4all.com[213.249.64.242]
Aug 31 21:38:01 johndoe postfix/smtpd[16200]: setting up TLS
connection from s097.networking4all.com[213.249.64.242]
Aug 31 21:38:01 johndoe postfix/smtpd[16200]:
s097.networking4all.com[213.249.64.242]: TLS cipher list
"ALL:!EXPORT:!LOW:!MEDIUM:+RC4:@STRENGTH"
Aug 31 21:38:01 johndoe postfix/smtpd[16200]:
SSL_accept:before/accept initialization
Aug 31 21:38:01 johndoe postfix/smtpd[16200]: SSL_accept:SSLv3 read
client hello B
Aug 31 21:38:01 johndoe postfix/smtpd[16200]: SSL_accept:SSLv3
write server hello A
Aug 31 21:38:01 johndoe postfix/smtpd[16200]: SSL_accept:SSLv3
write certificate A
Aug 31 21:38:01 johndoe postfix/smtpd[16200]: SSL_accept:SSLv3
write key exchange A
Aug 31 21:38:01 johndoe postfix/smtpd[16200]: SSL_accept:SSLv3
write server done A
Aug 31 21:38:01 johndoe postfix/smtpd[16200]: SSL_accept:SSLv3
flush data
Aug 31 21:38:02 johndoe postfix/smtpd[16200]: SSL_accept:SSLv3 read
client key exchange A
Aug 31 21:38:02 johndoe postfix/smtpd[16200]: SSL_accept:SSLv3 read
finished A
Aug 31 21:38:02 johndoe postfix/smtpd[16200]: SSL_accept:SSLv3
write change cipher spec A
Aug 31 21:38:02 johndoe postfix/smtpd[16200]: SSL_accept:SSLv3
write finished A
Aug 31 21:38:02 johndoe postfix/smtpd[16200]: SSL_accept:SSLv3
flush data
Aug 31 21:38:02 johndoe postfix/smtpd[16200]: Anonymous TLS
connection established from
s097.networking4all.com[213.249.64.242]: TLSv1 with cipher DHE-RSA-
AES256-SHA (256/256 bits)
Aug 31 21:38:02 johndoe postfix/smtpd[16200]: NOQUEUE: reject:
CONNECT from s097.networking4all.com[213.249.64.242]: 554 5.7.1
: Client host rejected:
Access denied; proto=SMTP
Aug 31 21:38:02 johndoe postfix/smtpd[16200]: disconnect from
s097.networking4all.com[213.249.64.242]
Aug 31 21:38:02 johndoe postfix/smtpd[16200]: connect from
s097.networking4all.com[213.249.64.242]
Aug 31 21:38:02 johndoe postfix/smtpd[16200]: setting up TLS
connection from s097.networking4all.com[213.249.64.242]
Aug 31 21:38:02 johndoe postfix/smtpd[16200]:
s097.networking4all.com[213.249.64.242]: TLS cipher

Building from source on CentOS

2011-09-05 Thread Nikolaos Milas 

Hello,

To build on CentOS from source and get an installation with standard 
features (as provided in CentOS standard Postfix RPMs) we use:


make makefiles \
CCARGS='-fPIC -DUSE_TLS -DUSE_SSL -DUSE_SASL_AUTH \
-DUSE_CYRUS_SASL -DPREFIX=\"/usr\" \
-DHAS_LDAP -DLDAP_DEPRECATED=1 \
-DHAS_PCRE -I/usr/include/openssl \
-I/usr/include/sasl  -I/usr/include' \
AUXLIBS='-L/usr/lib64 -L/usr/lib64/openssl -lssl -lcrypto \
-L/usr/lib64/sasl2 -lsasl2 -lpcre -lz -lm -lldap -llber \
-Wl,-rpath,/usr/lib64/openssl -pie -Wl,-z,relro' \
OPT='-O' \
DEBUG='-g'

Could you please tell me how to define custom settings for include and 
library directories?


I tried adding settings for custom include and library directories:

make makefiles \
CCARGS='-fPIC -DUSE_TLS -DUSE_SSL -DUSE_SASL_AUTH \
-DUSE_CYRUS_SASL -DPREFIX=\"/usr\" \
-DHAS_LDAP -DLDAP_DEPRECATED=1 -I/usr/local/openldap/include\
-DHAS_PCRE -I/usr/include/openssl \
-I/usr/include/sasl  -I/usr/include' \
AUXLIBS='-L/usr/lib64 -L/usr/local/openldap/lib64 -L/usr/lib64/openssl 
-lssl -lcrypto \

-L/usr/lib64/sasl2 -lsasl2 -lpcre -lz -lm -lldap -llber \
-Wl,-rpath,/usr/lib64/openssl -pie -Wl,-z,relro' \
OPT='-O' \
DEBUG='-g'

and "make" worked this way, but when I tried "make upgrade", it failed 
with messages that ldap libraries could not be found.


What am I doing wrong?

Thanks,
Nick




smime.p7s
Description: S/MIME Cryptographic Signature

Re: Postfix TLS: SSL3_GET_CLIENT_HELLO:no shared cipher

2011-09-05 Thread Wietse Venema 
wh...@hushmail.com:
> Aug 31 21:38:14 johndoe postfix/smtpd[16200]:
> s097.networking4all.com[213.249.64.242]: TLS cipher list
> "ALL:!EXPORT:!LOW:!MEDIUM:+RC4:@STRENGTH"
...
> smtpd_tls_security_level = may
> smtpd_tls_mandatory_ciphers = medium
> smtp_tls_protocols = !SSLv2, !SSLv3

Comment out all your smtpd_tls lines (including the lines that you
did not show) until the output from the command "postconf -n" shows
only these four:

smtpd_tls_CAfile
smtpd_tls_cert_file
smtpd_tls_key_file
smtpd_tls_security_level

Then add back your tweaks one by one (executing the command "postfix
reload" after each change) and learn which change breaks inter-operability.

You may also find some helpful hints in www.postfix.org/TLS_README.html.

Wietse

Re: Building from source on CentOS

2011-09-05 Thread Wietse Venema 
Nikolaos Milas:
> Hello,
> 
> To build on CentOS from source and get an installation with standard 
> features (as provided in CentOS standard Postfix RPMs) we use:
> 
> make makefiles \
> CCARGS='-fPIC -DUSE_TLS -DUSE_SSL -DUSE_SASL_AUTH \
> -DUSE_CYRUS_SASL -DPREFIX=\"/usr\" \
> -DHAS_LDAP -DLDAP_DEPRECATED=1 \
> -DHAS_PCRE -I/usr/include/openssl \
> -I/usr/include/sasl  -I/usr/include' \
> AUXLIBS='-L/usr/lib64 -L/usr/lib64/openssl -lssl -lcrypto \
> -L/usr/lib64/sasl2 -lsasl2 -lpcre -lz -lm -lldap -llber \
> -Wl,-rpath,/usr/lib64/openssl -pie -Wl,-z,relro' \
> OPT='-O' \
> DEBUG='-g'
> 
> Could you please tell me how to define custom settings for include and 
> library directories?

See: http://www.postfix.org/INSTALL.html, which is appropriately
titled "Postfix Installation From Source Code", section 4.

Wietse

Re: Configuring a mail gateway

2011-09-05 Thread Nikolaos Milas 

On 3/9/2011 11:09 μμ, Noel Jones wrote:


If we use:

relay_recipient_maps =

(that is, empty) then *all* recipients for the hosted domains (those
listed in relay_domains) are accepted/forwarded?
Yes.  That turns you into a backscatter source, clogging your queue
with undeliverable mail and eventually getting you blacklisted.

Not recommended.


OK, I understand.


Is there a way we can configure the gateway server to ask the final
delivery server (as defined in /etc/postfix/transport) whether the
user is valid and decide to allow or reject the mail transfer? In
this way we don't have to maintain a list of recipients.

http://www.postfix.org/ADDRESS_VERIFICATION_README.html

This requires that the next-hop server reply with a 5xx response to
nonexistent recipients.


So, in order to implement such a solution, would it be sufficient to do 
something like the following, on the *gateway* mail server:


   smtpd_recipient_restrictions =
 permit_mynetworks, reject_unverified_recipient,
   reject_unauth_destination

and on the *final destination* (next hop) mail server:

   unverified_recipient_reject_code = 550

...??

I guess this is what you mean by "active recipient verification". Right?

Thanks again,
Nick




smime.p7s
Description: S/MIME Cryptographic Signature

Re: Postfix TLS: SSL3_GET_CLIENT_HELLO:no shared cipher

2011-09-05 Thread Greg Hackney 

wh...@hushmail.com wrote:

The thing is I'm trying to check my SSL configuration using this
tool:
http://www.networking4all.com/en/support/tools/site+check/report/

and while it can validate mt certificate just fine, it says that it
can't establish a secure connection.
  


Be aware that test site looks at SMTPS port 465, and not STARTTLS over 
port 25.


Make sure that master.cf has any -o options for smtps that you might 
require.

Re: Configuring a mail gateway

2011-09-05 Thread Nikolaos Milas 

On 5/9/2011 3:26 μμ, Nikolaos Milas wrote:

So, in order to implement such a solution, would it be sufficient to 
do something like the following, on the *gateway* mail server:


   smtpd_recipient_restrictions =
 permit_mynetworks, reject_unverified_recipient,
   reject_unauth_destination

and on the *final destination* (next hop) mail server:

   unverified_recipient_reject_code = 550

...??

I guess this is what you mean by "active recipient verification". Right?




...and, if so, I guess we *still* need the directive:

   relay_recipient_maps =

(empty) ??

Nick



smime.p7s
Description: S/MIME Cryptographic Signature

Re: Disabling SSLv2 does not work as expected

2011-09-05 Thread /dev/rob0 
On Friday 02 September 2011 12:25:55 Michael B Allen wrote:
> On Fri, Sep 2, 2011 at 12:41 PM, Wietse Venema 
 wrote:
> > Michael B Allen:
> >> I am using postfix 2.3 on CentOS and I would like to disable
> >> SSLv2. If I do the following:
...
> I have to stick to the CentOS package so that I get updates.

It would appear that this is not working out well for you. That is: 
the updates you are hoping to see are not forthcoming.

When I set up a mail server on RHEL some time back, I used SRPMs to 
install a more recent Postfix version.
-- 
Offlist mail to this address is discarded unless
"/dev/rob0" or "not-spam" is in Subject: header

Re: Disabling SSLv2 does not work as expected

2011-09-05 Thread Michael B Allen 
On Fri, Sep 2, 2011 at 10:19 PM, Noel Jones  wrote:
> On 9/2/2011 2:17 PM, Michael B Allen wrote:
>> My objectives are not driven by or based on logic. They are based on
>> the requirements of a consortium of credit card companies and banks.
>
> Do they require you to offer STARTTLS on port 25?

My understanding is that PCI compliance requires only that the machine
processing cardholder data pass a vulnerability scan with no CVE
vulnerabilities of level 4 or higher. So the presence of SSLv2 in
general is considered a vulnerability. PCI says nothing of what can be
running on a machine or what ports they use. You can dispute something
with a scan by supplying an explanation as to why you believe the
particular CVE is not applicable but I have since stopped working on
the vulnerability scan because I have learned that this particular
vulnerability scanning vendor clears all disputes every 90 days.
Meaning I would have to re-enter them every 90 days and the UI for
doing that is a Flash application so I cannot just re-submit something
like a spreadsheet. Because I am using CentOS which backports many
security updates, this would be an enormous amount of work. My extra
sensory perception tells me that the whole process is actually
designed to make it excessively difficult to become PCI compliant. If
you are not PCI compliant, you can process cardholder data (as I have
been for several years) but you have greater liability if that data is
stolen thus leaving the credit card companies and banks with less
liability.

Mike

Re: Disabling SSLv2 does not work as expected

2011-09-05 Thread Noel Jones 
On 9/5/2011 10:50 AM, Michael B Allen wrote:
> On Fri, Sep 2, 2011 at 10:19 PM, Noel Jones  wrote:
>> On 9/2/2011 2:17 PM, Michael B Allen wrote:
>>> My objectives are not driven by or based on logic. They are based on
>>> the requirements of a consortium of credit card companies and banks.
>>
>> Do they require you to offer STARTTLS on port 25?
> 
> My understanding is that PCI compliance requires only that the machine
> processing cardholder data pass a vulnerability scan with no CVE
> vulnerabilities of level 4 or higher. So the presence of SSLv2 in
> general is considered a vulnerability. PCI says nothing of what can be
> running on a machine or what ports they use.

So the obvious solution is to disable opportunistic STARTTLS on port
25 until your next upgrade.

Or separate your mail and https servers to different IP addresses so
it's "not the same server".


  -- Noel Jones

Re: Configuring a mail gateway

2011-09-05 Thread Noel Jones 
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 9/5/2011 7:26 AM, Nikolaos Milas wrote:
> On 3/9/2011 11:09 μμ, Noel Jones wrote: So, in order to
> implement such a solution, would it be sufficient to do
> something like the following, on the *gateway* mail server:
> 
> smtpd_recipient_restrictions = permit_mynetworks,
> reject_unverified_recipient, reject_unauth_destination

Typically the order would be
smtpd_recipient_restrictions =
  permit_mynetworks
  reject_unauth_destination
  (local UCE controls)
  reject_unverified_recipient

ie. do the "expensive" recipient verification as late as possible
- -- it should always be after "permit_mynetworks,
reject_unauth_destination".


> 
> and on the *final destination* (next hop) mail server:
> 
> unverified_recipient_reject_code = 550

Yes.

> I guess this is what you mean by "active recipient
> verification". Right?

Yes.

> ...and, if so, I guess we *still* need the directive:
> 
> relay_recipient_maps =
> 
> (empty) ??

Yes, you'll be using reject_unverified_recipient for all your
relay_domains, so the explicit listing isn't needed.


  -- Noel Jones
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.17 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iQEcBAEBAgAGBQJOZPZAAAoJEJGRUHb5Oh6gncwH/j8RbF9z0uK8Q0mLk03ll7cS
ix+pFl5o8ZEYZZi3HsEZag9kJKpVZkjDJH73m4SCTGW+v69eEyK9oieWoTAYiVv+
XSzaUKzHXqU2eis5NcrJlRZ18j5X65YrZgAaExXULdcwScKRvI6q2x0KVr6E4jIi
Jc7AzhNBcy9+z/uMEuFG4ODc2iYOtI0mN9O4LxlbKa5Ql8cbgwxKWIoQuWQHuLOF
j/lsWVrQrNKgQLrWjjJfPftyt+iFv1HARJQ8fedpxJPMd3OGdT0zwNF0vP0Vezus
hKiAWBasmPdLevWePEvg2olrZlY4adw91JALghaK0gsDSmur8//4gwbd4/NrBQg=
=g4f9
-END PGP SIGNATURE-

Re: Disabling SSLv2 does not work as expected

2011-09-05 Thread Michael B Allen 
On Mon, Sep 5, 2011 at 12:07 PM, Noel Jones  wrote:
> On 9/5/2011 10:50 AM, Michael B Allen wrote:
>> On Fri, Sep 2, 2011 at 10:19 PM, Noel Jones  wrote:
>>> On 9/2/2011 2:17 PM, Michael B Allen wrote:
 My objectives are not driven by or based on logic. They are based on
 the requirements of a consortium of credit card companies and banks.
>>>
>>> Do they require you to offer STARTTLS on port 25?
>>
>> My understanding is that PCI compliance requires only that the machine
>> processing cardholder data pass a vulnerability scan with no CVE
>> vulnerabilities of level 4 or higher. So the presence of SSLv2 in
>> general is considered a vulnerability. PCI says nothing of what can be
>> running on a machine or what ports they use.
>
> So the obvious solution is to disable opportunistic STARTTLS on port
> 25 until your next upgrade.

Hi Noel,

I tried that and I immediately got a call from a customer saying they
got a "STARTTLS" error tyring to send me a mail. And they also tried
Yahoo mail which I guess doesn't use encryption either (which is
slightly surprising actually). So it seems there are quite a few
people out there still sending plaintext mail.

> Or separate your mail and https servers to different IP addresses so
> it's "not the same server".

This was actually my first thought. But I think in practice juggling
two servers that each handling some requirements will not necessarily
be easier than juggling one that handles all of the requirements.

Mike

Re: Issue integrating with Cyrus-SASL

2011-09-05 Thread Crazedfred 
> If you use the pass above, change it now that you have sent it to public.

I am substituting in fake accounts and passwords to show what's going on, these 
do not match what I am actually using :)

> Where did you put smtpd.conf? On Debian it should be in
> /etc/postfix/sasl/smtpd.conf.

On my system that file did not exist (the sasl directory is emtpy), it was 
located at /usr/lib/sasl2/smtpd.conf
The only lines are the ones I put there:

pwcheck_method: saslauthd
mech_list: login plain

> Do you run Postfix smtpd chrooted?

Not to my knowledge; I am running a pretty default install.
How could I confirm that?

> You seem to be generating your base64 hash incorrectly, putting literal
> "<00>" in the hash instead of the null character.  See the following for
> info on how to correctly generate the hash:
> http://www.postfix.org/SASL_README.html#server_test

The \000 is apparently just a different escape character.
From http://qmail.jms1.net/test-auth.shtml:

"... if you use \0 as the separator, and the userid or password happens to 
start with a digit, perl will try to find and use a three-digit octal character 
code instead of a one-digit null byte with two normal digits behind it. Using 
\000 instead of just \0 prevents this from happening."

At any rate, the result is the same regardless:

perl -MMIME::Base64 -e 'print encode_base64("\0test\@example.com\0testtest123")'
AHRlc3RAZXhhbXBsZS5jb20AdGVzdHRlc3QxMjM=
perl -MMIME::Base64 -e 'print 
encode_base64("\000test\@example.com\000testtest123")'
AHRlc3RAZXhhbXBsZS5jb20AdGVzdHRlc3QxMjM=

Re: Disabling SSLv2 does not work as expected

2011-09-05 Thread Noel Jones 
On 9/5/2011 11:19 AM, Michael B Allen wrote:
> On Mon, Sep 5, 2011 at 12:07 PM, Noel Jones  wrote:
>> On 9/5/2011 10:50 AM, Michael B Allen wrote:
>>> On Fri, Sep 2, 2011 at 10:19 PM, Noel Jones  wrote:
 On 9/2/2011 2:17 PM, Michael B Allen wrote:
> My objectives are not driven by or based on logic. They are based on
> the requirements of a consortium of credit card companies and banks.

 Do they require you to offer STARTTLS on port 25?
>>>
>>> My understanding is that PCI compliance requires only that the machine
>>> processing cardholder data pass a vulnerability scan with no CVE
>>> vulnerabilities of level 4 or higher. So the presence of SSLv2 in
>>> general is considered a vulnerability. PCI says nothing of what can be
>>> running on a machine or what ports they use.
>>
>> So the obvious solution is to disable opportunistic STARTTLS on port
>> 25 until your next upgrade.
> 
> Hi Noel,
> 
> I tried that and I immediately got a call from a customer saying they
> got a "STARTTLS" error tyring to send me a mail. And they also tried
> Yahoo mail which I guess doesn't use encryption either (which is
> slightly surprising actually). So it seems there are quite a few
> people out there still sending plaintext mail.

Get your users to configure their mailer to send to either port
587/submission or the legacy 465/smtps, and configure postfix for
mandatory encryption on those ports.  This is good practice
regardless of PCI requirements.


> 
>> Or separate your mail and https servers to different IP addresses so
>> it's "not the same server".
> 
> This was actually my first thought. But I think in practice juggling
> two servers that each handling some requirements will not necessarily
> be easier than juggling one that handles all of the requirements.

One server; configure apache to listen on a different IP.


  -- Noel Jones

Re: Issue integrating with Cyrus-SASL

2011-09-05 Thread Patrick Ben Koetter 
* Crazedfred :
> > If you use the pass above, change it now that you have sent it to public.
> 
> I am substituting in fake accounts and passwords to show what's going on, 
> these do not match what I am actually using :)
> 
> > Where did you put smtpd.conf? On Debian it should be in
> > /etc/postfix/sasl/smtpd.conf.
> 
> On my system that file did not exist (the sasl directory is emtpy), it was 
> located at /usr/lib/sasl2/smtpd.conf
> The only lines are the ones I put there:
> 
> pwcheck_method: saslauthd
> mech_list: login plain

If you run Postfix from Debian packages, you need to locate smtpd.conf at
/usr/lib/sasl2/smtpd.conf.

You also need to add the postfix user to the sasl group:

% adduser postfix sasl


> > Do you run Postfix smtpd chrooted?
> 
> Not to my knowledge; I am running a pretty default install.

Then it very likely is chrooted.

> How could I confirm that?

1. Check the chroot column for the smtp service in master.cf
2. Run saslfinger. It will generate a report useful for debugging Cyrus SASL
   on this list.

If it runs chrooted and if you want to stick with that you need to change the
location where saslauthd puts the socket. On Debian you edit OPTIONS at the
bottom of /etc/default/saslauthd:

OPTIONS="-c -m /var/spool/postfix/var/run/saslauthd"

Then restart saslauthd using the init-script. It will create all necessary
paths and set all permissions to establish the socket in
/var/spool/postfix/var/run/saslauthd.

p@rick

-- 
All technical questions asked privately will be automatically answered on the
list and archived for public access unless privacy is explicitely required and
justified.

saslfinger (debugging SMTP AUTH):

Re: Disabling SSLv2 does not work as expected

2011-09-05 Thread Michael B Allen 
On Mon, Sep 5, 2011 at 12:32 PM, Noel Jones  wrote:
> On 9/5/2011 11:19 AM, Michael B Allen wrote:
>> On Mon, Sep 5, 2011 at 12:07 PM, Noel Jones  wrote:
>>> Or separate your mail and https servers to different IP addresses so
>>> it's "not the same server".
>>
>> This was actually my first thought. But I think in practice juggling
>> two servers that each handling some requirements will not necessarily
>> be easier than juggling one that handles all of the requirements.
>
> One server; configure apache to listen on a different IP.

Wow. That is actually a great idea. The vulnerability scan will have
no clue. It's almost like cheating. I love it.

Thanks,
Mike

Re: Postfix TLS: SSL3_GET_CLIENT_HELLO:no shared cipher

2011-09-05 Thread whizz 
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On Mon, 05 Sep 2011 19:21:27 +0700 Wietse Venema
 wrote:
>>wh...@hushmail.com:
>> Aug 31 21:38:14 johndoe postfix/smtpd[16200]:
>> s097.networking4all.com[213.249.64.242]: TLS cipher list
>> "ALL:!EXPORT:!LOW:!MEDIUM:+RC4:@STRENGTH"
>...
>> smtpd_tls_security_level = may
>> smtpd_tls_mandatory_ciphers = medium
>> smtp_tls_protocols = !SSLv2, !SSLv3
>
>Comment out all your smtpd_tls lines (including the lines that you
>did not show) until the output from the command "postconf -n"
>shows
>only these four:
>
>smtpd_tls_CAfile
>smtpd_tls_cert_file
>smtpd_tls_key_file
>smtpd_tls_security_level
>
>Then add back your tweaks one by one (executing the command
>"postfix
>reload" after each change) and learn which change breaks inter-
>operability.
>
>You may also find some helpful hints in
>www.postfix.org/TLS_README.html.
>
>   Wietse

I did, I went as far as installing Postfix on a vanilla system on
different distro (Ubuntu server).
I can confirm even only with those four smptd_tls lines the result
is no different.

hack...@cincomail.com wrote:

>wh...@hushmail.com wrote:
>> The thing is I'm trying to check my SSL configuration using this
>> tool:
>>
http://www.networking4all.com/en/support/tools/site+check/report/
>>
>> and while it can validate mt certificate just fine, it says that
it
>> can't establish a secure connection.
>>

Be aware that test site looks at SMTPS port 465, and not STARTTLS
over
port 25.

Make sure that master.cf has any -o options for smtps that you
might
require.

Thanks for pointing that out. Tcpdump does confirm that
networking4all.com tool only probes port 465 on its smtps check.

This is my current master.cf config:

(. . . . .)

smtp  inet  n   -   -   -   -   smtpd
#submission inet n   -   -   -   -   smtpd
#  -o smtpd_tls_security_level=encrypt
#  -o smtpd_sasl_auth_enable=yes
#  -o smtpd_client_restrictions=permit_sasl_authenticated,reject
#  -o milter_macro_daemon_name=ORIGINATING
smtps inet  n   -   -   -   -   smtpd
  -o smtpd_tls_wrappermode=yes
  -o smtpd_sasl_auth_enable=yes
  -o smtpd_client_restrictions=permit_sasl_authenticated,reject
  -o milter_macro_daemon_name=ORIGINATING

(. . . . )

Anything I should change?

FWIW Outlook is able connect to port 465 using SASL.

Interestingly, networking4all.com smtp server
(smtp.networking4all.com) is also using postfix and it can pass its
own tool.
I wonder what config do they put in main.cf and master.cf

Thank you for your reply, Wietse and Greg.
-BEGIN PGP SIGNATURE-
Charset: UTF8
Version: Hush 3.0
Note: This signature can be verified at https://www.hushtools.com/verify

wsBcBAEBAgAGBQJOZatBAAoJEIsVW8QaqqJOXjMH/jt/FU6NQ91vCxgzXhJuAeLFlsQM
rDV/vThEvPQICM2jeBF04eSHB9RrcDavDA/GHopzfImQ8Gd4FYu3Wr0mm0AqJnZvu0Pl
q6Klb0IaxoRkvzClQPdWnwuUYtcgRyIjjCNREBkXaOawA2xoHmlAg9zBjJP9dPzzZvKP
kSbVoDUKOqpDGljmShQ/m30Hi2QFxsewvYlk4iIQN9MVyhpgdO1TThhonh3HryMNTaY2
WRB1fgxvCytRcNV1DoIqsz2IrNgrqnnkS9hOPTBpw4TIpxPqJR7DZDsKtE+3qYX64nYS
H6pkNuP1tJ2irBjFhOeUooXrcP9ATFvkiqBsDjzM18w=
=yXDf
-END PGP SIGNATURE-