Thanks for all this attention to my problem.
I would like to give a little history as to perhaps why port 465
authentication is required.
VirginMedia (and NTLWorld, therefore) appear to sub out their e-mail
handling to GMail. All the webmail appears the same but is branded VM. A
few years ago both GMail and VM said they would require authentication
on port 587 and this was enabled. If you just used port 587 GMail and VM
rewrote the e-mail "from" headers to your GMail/NTLWorld e-mail address
which was very annoying when you were sending from
your_name@your_domain.com. In their set up they then allowed you to
specify up to 10 e-mail addresses where they would not rewrite the
headers and this worked. VM never enforced authentication at the time so
I switched back to port 25, but they turned it on a few days ago on port
465 and not 587.
Investigating GMail's port 587 relaying again, you can no longer add
e-mail addresses from, say, your_name@your_domain.com. It pops up a
message about saying your_domain.com does not permit them to relay these
messages and will not accept your set up. VM's set up is the same. But
it looks like VM may be aware of this so they closed port 587 and opened
port 465 and it appears that using port 465 it does not rewrite the
headers at all. This is, perhaps, their way of getting round GMail's
restriction where you can no longer add addresses you'd like to relay
untouched. Yes, it is an old method, but it gets round GMail's
restriction (for the moment).
You may wonder why I do not send mails directly. The main reason is that
I have a (not very) dynamic IP, and because it is dynamic, it is
automatically on the SORBS blacklist. It is not on any others that I can
see.
In the meanwhile as it will probably take ages for RHEL to incorporate
your patches and upgrade to the latest version (I think I'm on 2.6.6-6
but I'd need to check at home) I'll follow your suggestion and look at
stunnel.
Thanks again,
Nick
On 2015-01-15 04:57, Viktor Dukhovni wrote:
On Thu, Jan 15, 2015 at 03:20:27AM +0000, Viktor Dukhovni wrote:
And of course with "may", we need to avoid any attempt at cleartext
fallback if we're doing wrapper-mode SMTP.
With the previous posttls-finger patch, it was still possible to
attempt both wrapper-mode (-w) and TLS disabled (-l none). This
ended up attempting to send "QUIT" as the sole cleartext command
to an SSL server.
I am attaching a slightly more comprehensive patch, which also
cleans up a bit of kludge in how "dane-only" was implemented. Now
it no longer automagically morphs to "dane" after successful TLSA
lookup. Instead the level-related in tls.h are extended to add
TLS_DANE_BASED - either "dane" or "dane-only"
TLS_OPPORTUNISTIC - either "may" or "dane"
which can be used when appropriate. The resulting code is cleaner
I think (wrapper-mode aside). Just 3 extra lines of code, outside
the changes to posttls-finger to support wrapper-mode.
This patch works with either the latest nonprod or regular 2.12
snapshot and does not conflict with the "sslbitrot" patch to address
future upstream changes in the OpenSSL development branch. So please
apply both when you get a chance.
As for wrapper mode, I think it should insist on the destinations
security level being neither disabled nor opportunitic as in the
revised posttls-finger. Something along the lines of:
+ if (state->wrapper_mode
+ && (state->level <= TLS_LEV_NONE
+ || TLS_OPPORTUNISTIC(state->level))) {
+ msg_info("Failed to establish session to %s via %s: %s",
+ dest, HNAME(addr),
+ "SSL wrapper-mode requires mandatory TLS");
+ continue;
+ }
The trouble with allowing "may" in wrapper-mode is that we'd
otherwise need to change the logic that implements cleartext
fallback, future audit logs, ...
The trouble with "dane" is more of a judgement call, "dane" may
work when originally tested, provided TLSA records are published
for port 465, and later revert to "may" and break if TLSA records
are removed by the domain owner. This triggers potentially misleading
error messages. Since "dane" is effectively mandatory in wrapper-mode,
why not say so by specifying dane-only"?
