On Fri March 4 2005 00:19, Keith Moore wrote:
Well, current SMTP specifications allow for anyone to use any domain
in either the rfc2821 identities, or any place in rfc2822. All
authentication schemes intend to change that.
AFAIK, none of SSL, TLS, or SMTP AUTH make any such change.
well, it depends on what you mean by "being able to use any domain"
Well, that was Wayne's comment. From my perspective (as a mobile
user (i.e. connecting via an unpredictable IP address) with need
to use only a few domain names) I'd phrase the issue as "being
able to use any IP address"; and that's where SPF utterly fails.
To be precise, I mean that when sending mail, I need to specify
a mailbox in the return path which uses my ISP's domain name
(because that (my mailbox) is where legitimate bounces should go)
and likewise in the From and/or Reply-To and/or Sender fields of
the message header -- regardless of my IP address, and regardless
of the ISP that I happen to be sending the message(s) via, if I
use an ISP's SMTP relay, and regardless of whether I choose to
use such a relay (e.g. to store a single copy of a message for
distribution to multiple recipients) or to directly connect to
the designated MX host(s) for the message recipient(s).
for instance, SSL/TLS server certificates do not allow the server to
[convincingly] claim to be any domain it wants to be within the SSL/TLS
protocol. they don't try to restrict the server's domain name
according to the IP address,
or the client's!
and they don't inherently impose
constraints on what domains the protocols layered over SSL or TLS use.
in the case of email, it's generally not
reasonable for an SMTP client or server to expect the domains in EHLO,
HELO, MAIL, or RCPT to match those used at the SSL or TLS layer,
because third-party relaying is an extremely useful feature of the SMTP
architecture.
And SMTP AUTH provides for SMTP session authentication independent
of transport layer security, and without imposing unreasonable
restrictions on IP address or domain name.