On Mon, Dec 24, 2001 at 11:56:13PM +0100, Lukasz Grochal wrote:
> Matthew Byng-Maddick <exim@???> writes:
> > On Mon, Dec 24, 2001 at 02:45:16AM +0100, Lukasz Grochal wrote:
> > [both to me, and to the list, as I explicitly asked him not to]
> Listen, my (presumably) young and hasty friend. Listen carefully
> and try to understand: I DID NOT. Now go and try to check what
I'm sorry that I don't bother checking every single one of my messages.
When I receive two copies of the same message, I generally find that this
is what has happened, what has actually happened is that:
> I actually did (hint: a mistake in this case - go, read the
> Received headers, you know where to look for them).
You were presumably clueless and sent the same message three times to the
list.
> >> Great, OK. That means the host in question MUST NOT be a public MX for
> >> the domain. I hope that's clear and I won't elaborate on that issue.
> > Your *wrong* opinion. This is discriminatory to people who only have one
> > IP addresses.
> Now again, my friend. Go and read RFC2822. It clearly says, an MX MUST
> accept mail for postmaster@<domain>. Now as you've learned that we can
> go on.
I'm well aware of this. I'm not saying it shouldn't. Given that you are
trying to tell me this, I presume that at some point we've ended up talking
cross purposes. I'll put my argument quite simply here, and then try and
clear up the cross purposes.
My argument is that, just because a host says in the EHLO banner line
250-STARTTLS that you shouldn't assume you can do TLS to it. The reason
for this is that TLS includes all sorts of other requirements which cannot
be communicated in-band in SMTP, for example client certificates. Therefore
an outbound mailer *SHOULD NOT* be configured to do TLS to any host that
advertises the STARTTLS feature.
Your argument, that any host which advertises TLS should allow me to
establish a TLS connection is rather like saying "just because a host
allows me to do SMTP AUTH, I should send it my username and password,
just in case".
That is what I'm trying to say. The relay situation was one example of
where you might want client certificates, although you've kind of taken
that as the only reason for wanting them (by the looks of your message).
> > I've given you a good example where it does hurt, you chose to say that
> > I was wrong, but your own cluelessness shows through.
> And this is because I've told you that a public MX set up so that it
> refuses mail sent without encryption is simply useless and such an
> MX refusing unencrypted mail to postmaster is simply illegal? Good.
No. That's nothing to do with it. As I said, we're talking cross purposes.
What I'm talking about is where you have elevated privileges by using
certificate authenticated TLS. I agree that if you have a public MX, then
you should always accept unencrypted mail. I'm not disputing that. What I
am, however, disputing is that you should be able to do TLS (and deliver
the mail to postmaster@) just because I advertised STARTTLS.
> > You're talking crap! I've given you a particularly good example of where
> > it doesn't work.
> And demand me to say that because of that (surely weird and requiring
> special router setup anyways) particular example I should admit, that
> misconfigured hosts I've initially described don't actually exist? Good.
Huh? The misconfigured hosts you've described are the ones who try doing
STARTTLS with no prior agreement, not the ones who advertise it, and then
refuse to complete the connection if a valid client cert is not presented.
> > What you missed, is that you can't communicate that a client certificate
> > is required, in band with the STARTTLS command. By not being able to do
> > this, then trying to do encryption just because a host advertises STARTTLS
> > is obviously wrong, because you don't know what the policies required of
> > you are.
> That's your point of view. And I won't comment on that, just read on.
No, it's plain fact. You can't communicate the other parts of the TLS
protocol when you advertise STARTTLS in your EHLO line, therefore you
can't say that certificate-based authentication is needed to make the
connection set up properly.
> > Well, IKE is not exactly a simple protocol to understand.
> You clearly don't understand what I'm talking about. Both when I'm talking
> about SMTP and MX-es and when I talk about encryption. Please, go read
> <http://www.freeswan.org/freeswan_trees/freeswan-1.91/doc/config.html>,
> the part on opportunistic encryption, and perhaps <http://www.freeswan.org/
> freeswan_trees/freeswan-1.91/doc/politics.html> Then come back and we'll
> discuss the issue again if you wish.
I know a fair bit about how encryption works, I don't really need someone
to patronise me in this way. This discussion has nothing to do with IPSec,
that is a diversion. This is about TLS, and specifically TLS in-band as a
part of ESMTP.
> Now, to conclude: I usually don't answer people that ex cathedra produce
> ad personam arguments. I usually let them go back to the sandboxes, they
Nothing to do with it. Your mail has some nice ad hominem attacks on me
too, I note. So maybe you should follow your own advice?
> came from and mature. But I've found something interesting - in your whole
> article, neither this nor your previous one, you _never_ raised any
> practical issues regarding implementing fuctionality I requested. Neither
> you prove that it would break Exim in any way. The only thing you did was
> to say that both me and the idea are stupid.
Since you obviously have no idea how TLS works, (hint: the encryption is
actually the easy bit), there is a horrible set of negotiation about
each side asking the other for certificates, and accepting them or not.
It is possible, in TLS, to ask for a client certificate, and not to barf
and give up on the connection if you don't get one. This functionality
is addressed in Exim 4 (for the receiver-SMTP side "misconfiguration",
as you'll see a few messages up in the archives. The reason for this is
the ACLs of Exim4 make this possible in the configuration file.
It is very difficult, however, to express this functionality with the
limitations present in the Exim3 config file, let alone the fact that
the way in which the OpenSSL calls are done, in exim3, mean that if a
client certificate is requested and not presented, or if it is not a
valid one, then the connection is left in an undefined state.
There are several reasons I think your idea is stupid:
1) Since you may get elevated privileges (if you have agreed encryption
with the host) then doing it without TLS would mean that you could
conceivably end up with a bounce where you should have got a retry.
(at what point this happens is left as an exercise to the reader)
2) You need (for exim3 at least, new and extra nice bits in your hints
file, and so this is not a straight upgrade, for machines that have
large queues, that can't necessarily be flushed before an upgrade.
For this, you could lose the hints file, but I don't think that's a
particularly good idea for some installations.
3) The use of encryption should be "agreed" to by both parties, it is
a misconfigured host that tries to use encryption because it is
advertised as an ESMTP banner. Because you can't communicate the
necessary prerequisites in-band, then it is not reasonable for the
sender-SMTP to try it.
The above are not ad hominem attacks. They are, IMHO valid reasons for
not having the functionality you desire. I, personally, think such
functionality would be extremely confusing for other users.
MBM
--
Matthew Byng-Maddick <mbm@???> http://colondot.net/
