On 7 Mar 1994, Michael Nittmann, NITTMANN @
UWLAX .
EDU, wrote, in part...
>I would like to form an email based workgroup to update smtp.
I don't follow this list, but want to try to put a little perspective
on Michael's suggestion. This is going to be a little long, but I'm
feeling a need to respond both to some issues about how things happen
on the Internet and about some specific SMTP features.
_History_
Over the last have dozen years, IETF has had two different working
groups charged with "updating" smtp. The first was the "Host
Requirements" WG, which produced Internet Standard RFC1123. The second
was an "SMTP extensions" group, which produced standards-track RFCs
1425, 1426, and 1427. The first of these specifies a general model for
_extending_ SMTP by permitting the sending-SMTP ("client") to request
special services from the server-SMTP. A third WG has just been
launched to deal with notifications of various sorts. It is expected
to define standards for delivery notifications, for message formats for
non-delivery notifications. I suspect that it will do some work on
explicit tracing mechanisms as well. More on that WG and how people
can participate in it below.
>smtp has various places where empty strings are used as loop
>breakers.
Only one of these is standard, and the issue is primarily the
unambiguous identification of error messages and only secondarily the
prevention of loops.
>A side effect is that not in all instances, especially in error
>cases, a complete traceback verification can be achieved.
Complete and accurate traceback verification can *never* be reliably
achieved. In any event, the most important tool for traceback
identification with conforming SMTP implementations is the Received
fields inserted into the message headers, not the reverse-path.
>I would like to invite interested parties to discuss this off line,
>how to replace the empty string notations by adequately flagged
>strings that can be used in a secure firewall smtp server to verify
>the complete reverse path of a message.
Going backwards--trying to undo a firm standard and replace it with
some other notion--almost never works. Getting agreement and a
meaningful level of deployment is just too hard. You should try to
figure out what you really need, and why, and then design something
that does it, rather than trying to overload an existing facility by
changing its meaning.
In this specific case, the traceback information that would appear if
the empty reverse path convention was not used might not do you any
good anyway. RFC1123 explicitly permits a receiving host to route a
non-delivery message by using only the domain name of the originating
host, rather than the reverse path. If this is done, the error message
may take a different path back than the undeliverable original message
took "forward".
> 2) achive a situation where obvious mail fraud can be
>immediately recognized
This is either tautological (i.e., "mail fraud" is "obvious" iff it can
be "immediately recognized") or cannot be realized no matter what you
do to the envelope.
> 3) relieve firewall mailers from having to support anonymous email
You aren't required to do this today. If you don't like what is in the
envelope, you are free to reject the message. Nothing in the Internet
requires a receiving system to accept any particular piece of mail, nor
are there restrictions on the reasons for rejection. The only thing
you must not do is to send a mailed rejection message back in response
to a message with a null return path.
The fly in this ointment is, of course, your own users: if you start
rejecting things that they had expected to receive in order to protect
them from themselves, you will sooner or later make them very unhappy.
And, if they have any power, the people making the rejection decisions
will find themselves replaced by people with a more relaxed attitude.
That scenario has been played out over and over again in different
organizational settings.
> 4) make interactive exploration of smtp mailers at least more difficult
You probably wouldn't want to do this even if you could. While
"interactive exploration" can be a tool for someone trying to spoof
mail, it is also an invaluable resource -- especially via the VRFY and
EXPN commands -- for testing addresses and verifying the functionality
of servers.
If some particular type of tracing information would be useful for
supporting the firewall function as you see it, I'd suggest that you
join the new IETF WG on notifications and try to get it to see your
point of view on what information should be included in delivery and
non-delivery messages. IETF WGs do most of their work by email, so you
should have little difficulty participating even without attending IETF
plenaries. The charter for that WG can be obtained by anonymous FTP in
the directory ietf/notary from ds.internic.net (and other IETF shadow
sites). It contains information on the WG's mailing list and archive
as well as the charter itself and the WG's schedule.
The only way to prevent or reliably detect mail spoofing is, and will
remain, strong end-to-end authentication by digital signatures or the
equivalent. Anything else just raises the obscurity threshold a bit,
sometimes at the risk of creating a false sense of security.
John Klensin, klensin @
infoods .
unu .
edu
IETF Area Director for Applications
|
|
