[ On Tuesday, June 15, 2004 at 00:40:00 (-0500), Edgar Lovecraft wrote: ]
> Subject: Re: [Exim] AOL - SPF - and EXIM
>
> Here is were I disagree. SMTP is no more 'insecure' by nature than
> HTTP, POP, IMAP etc. The reason most people say that SMTP is insecure
> is because 'you cannot verify the sender'. That is true, and it is
> also not true.
Very true! :-)
But of course you don't really need to verify the "sender" address in
any "secure" way. The sender address is simply, and _only_, the address
to which DSN messages are to be sent. 99.999% of the time it should
_never_ be used for anything. All you _really_ need to know is that the
domain part is valid and is used for e-mail and perhaps that it has a
functioning mail server. Knowing that the mailbox part is valid can
help reduce the amount of manual maintenance a postmaster might
encounter if/when something does go wrong and then somehow the bounce
doesn't get through.
There's no defined relationship between the "sender" (return) address
and the sending-client-SMTP or even the "inside" from/reply address(es)
and any and all attempts to create such a relationship (e.g. SPF), can
only ever do so by defining some new SMTP variant that is not true SMTP.
> It is not true that we cannot 'verify' the source of the SMTP
> transaction however.
[[ ... ]]
> Proper DNS information
> is the only way to very the 'validity' of a client connection.
Ah ha! Yes, indeed!
> The only
> reason that we continue to see such broken DNS informaiton in relation
> to HELO/EHLO is because too many sites did not care to enforce what
> all the RFC's already say is the only proper and good pratice when
> initiating an SMTP transaction.
Indeed -- all too true.
> The majority of the work that people are now trying to do in fighting
> SPAM is going in the wrong direction in this respect.
True enough.
However if we do think in terms of going past the basic HELO parameter
verification then we might go on to consider to the idea I think I
raised here some time ago about having a simple SMTP extension for
server key exchange and verification that would allow postmasters to
sign each other's "server" PGP keys and to have a simple little knob to
twist to say how much trust you would need to have of a given server's
key before you accepted connections from it (and perhaps even vice versa
-- i.e. for sending too).
I.e. we don't need to force every user to use PGP directly end-to-end in
order to stop spam and similar abuses. Users might want to use PGP for
true e-mail security and end-to-end signature verification, but if we
can get enough postmasters out of the box(es) they've created in their
thinking such that we could reach critical mass with using inter-server
trust relationships to at least weed out the worst offenders then we'd
really be getting somewhere. E.g. if some server using a key your
server trusts sends you spam then at least you know _exactly_ who to
point your finger at and nobody (that you trust) can waffle out of
accepting responsibility for the e-mail their server sends.
> The first step in 'fighting SPAM' is to first start with enforcing
> the current standards, perhaps with a touch of re-wording, or
> stronger language (change SHOULDs to MUSTs for example) before we
> start complicating things with 'fixes' that are more complicated,
> unnecessary, and at times, out right broken.
Actually I don't think we need much change at all at the specifications
level beyond recinding the stupid RFC 1123 5.2.5 wording that assumes
all e-mail users can read and understand and interpret "received"
headers.
We don't have to require that people verify the HELO parameter, just
make it less of a "my reading of the RFC is better than your reading of
it" B.S. debate so that more people won't think they're disobeying one
of the Ten Commandments when they do verify client names and refuse
transactions from bogus or mis-configured clients.
--
Greg A. Woods
+1 416 218-0098 VE3TCP RoboHack <woods@???>
Planix, Inc. <woods@???> Secrets of the Weird <woods@???>
