Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

Problem relaying through Virginmedia (ntlworld) with authentication

25 views
Skip to first unread message

Nick Howitt

unread,
Jan 14, 2015, 4:27:01 PM1/14/15
to
Hi,

My ISP Virginmedia (VM) suddenly made authentication compulsory a couple of days ago. I use Thunderbird relaying through postfix. I did have it working a few years ago on port 587 but now they want port 465.

In main.cf I've set:
smtp_sasl_auth_enable = yes
smtp_sasl_security_options = noanonymous
relayhost = [smtp.ntlworld.com]:465
smtp_use_tls = yes

I've set the password correspondingly and "postmap -q [smtp.ntlworld.com]:465 /etc/postfix/sasl_passwd" returns my.us...@ntlworld.com:my_password.

With this set up I always fail with messages like:
Jan 14 17:34:43 server postfix/smtp[792]: 9F8F2E258E: to=<my.ac...@gmail.com>, relay=smtp.ntlworld.com[62.254.26.221]:465, delay=13, delays=0.03/0.08/13/0, dsn=4.4.2, status=deferred (lost connection with smtp.ntlworld.com[62.254.26.221] while receiving the initial server greeting)

I've tried with and without [ and ] - there is no MX record for smtp.ntlworld.com.

The same set up works fine with gmail.com on 587. Thunderbird connects and sends correctly directly to smtp.ntlworld.com on 465 with similar settings (normal password, SSL/TLS). It just seems that I can't get postfix to connect.

Can anyone help me?

Thanks,

Nick

Wietse Venema

unread,
Jan 14, 2015, 4:39:30 PM1/14/15
to
Nick Howitt:

> <html>
> <head>
>
> <meta http-equiv="content-type" content="text/html; charset=utf-8">
> </head>
> <body bgcolor="#FFFFFF" text="#000000">
> Hi,<br>
> <br>
> My ISP Virginmedia (VM) suddenly made authentication compulsory a
> couple of days ago. I use Thunderbird relaying through postfix. I
> did have it working a few years ago on port 587 but now they want
> port 465.<br>

Delivery to remote port 465 requires that you use stunnel.
Look with your favourite search engine for: postfix stunnel 465.

Delivery to port 465 is not built into the Postfix SMTP client
because that protocol has been obsolete for 10+ years. That said,
it would not take much code to support this in the SMTP client. I
guess it is not implemented for techo-religuous reasons.

Wietse

Viktor Dukhovni

unread,
Jan 14, 2015, 4:54:56 PM1/14/15
to
On Wed, Jan 14, 2015 at 09:26:32PM +0000, Nick Howitt wrote:

> In main.cf I've set:
> smtp_sasl_auth_enable = yes
> smtp_sasl_security_options = noanonymous
> relayhost = [smtp.ntlworld.com]:465

Port 465 is not STARTTLS and is not directly supported by Postfix:

http://www.postfix.org/TLS_README.html#client_smtps

Note the minimal stunnel.conf file in the example does not authenticate
the remote server, so that configuration is subject to man-in-the-middle
attacks.

To authenticate the remote peer with stunnel, even "verify = 2" is
not enough, as it completely ignores the subject name (and altnames)
in the peer's certificate, checking only that the certificate is
issued by a trusted CA. My attempts (some years back) to persuade
the author of stunnel to be more sensible failed.

Therefore, what you need to do is configure a CAfile in which in
addition to the expected trusted issuing root CA, you include a
copy of a leaf certificate with the same subject DN as the remote
peer's current certificate. Then with "verify = 3", stunnel will
verify the peer (until some part of the DN changes).

CA-based authentication of tunnels to peers you don't control is
sadly rather painful with stunnel.

Perhaps some day stunnel will support DANE (and offer a more
useful implementation of verify = 2).

--
Viktor.

Viktor Dukhovni

unread,
Jan 14, 2015, 5:15:33 PM1/14/15
to
On Wed, Jan 14, 2015 at 09:54:38PM +0000, Viktor Dukhovni wrote:

> Then with "verify = 3", stunnel will
> verify the peer (until some part of the DN changes).

In this case the subject DN does not appear to be decorated with
any particularly volatile data. The server's chain is:

subject=/C=GB/ST=Hampshire/L=Hook/O=Virgin Media Ltd/OU=internet operations/CN=smtp.ntlworld.com
issuer=/C=US/O=VeriSign, Inc./OU=VeriSign Trust Network/OU=Terms of use at https://www.verisign.com/rpa (c)10/CN=VeriSign Class 3 Secure Server CA - G3

subject=/C=US/O=VeriSign, Inc./OU=VeriSign Trust Network/OU=Terms of use at https://www.verisign.com/rpa (c)10/CN=VeriSign Class 3 Secure Server CA - G3
issuer=/C=US/O=VeriSign, Inc./OU=VeriSign Trust Network/OU=(c) 2006 VeriSign, Inc. - For authorized use only/CN=VeriSign Class 3 Public Primary Certification Authority - G5

subject=/C=US/O=VeriSign, Inc./OU=VeriSign Trust Network/OU=(c) 2006 VeriSign, Inc. - For authorized use only/CN=VeriSign Class 3 Public Primary Certification Authority - G5
issuer=/C=US/O=VeriSign, Inc./OU=Class 3 Public Primary Certification Authority

So a CAfile that includes the root CA cert for:

/C=US/O=VeriSign, Inc./OU=Class 3 Public Primary Certification Authority

and any cert with a subject name of:

/C=GB/ST=Hampshire/L=Hook/O=Virgin Media Ltd/OU=internet operations/CN=smtp.ntlworld.com

should do (stunnel just checks for a cert in the CAfile that matches
the peer's subject DN). For the latter, the following command
will, generate a suitable certificate (with a discarded private key):

openssl req -new -nodes -newkey rsa:2048 -keyout /dev/null \
-config <(printf "[req]\n%s\n%s\n[dn]\n" "prompt = yes" "distinguished_name = dn") \
-x509 -days $((365 * 100)) -subj "/C=GB/ST=Hampshire/L=Hook/O=Virgin Media Ltd/OU=internet operations/CN=smtp.ntlworld.com"

The above requires "bash", for <(command) in-line file-handles.
Your could use the below instead if you like:

--
Viktor.

0 new messages