Two questions/ comments about this note...
--On Sunday, 29 April, 2007 23:19 -0400 Hector Santos
<hsantos(_at_)santronics(_dot_)com> wrote:
...
Thoughts on an addition like this? I know it doesn't go far
enough for some people, and probably goes too far for some
other people. So I'm offering it as a possible way forward.
+1 and -1
Why +1?
...
Accepting a local forward-path without authentication is the
industry BCP. For a remote forward-path, requiring
authentication is the industry BCP, otherwise you may have
open-relay entry points and accept/bounce attack threat entry
points.
It is a "best practice" or even a "general current practice"
(the latter has, IMO, much more impact on 2821bis under the
rules than discussions of "best") iff "authentication" is taken
very broadly. The reality, as I have observed it, is that it is
general, current, and best practice to prevent open relay
behavior. But that is as often done by validating the sender in
some fashion rather than validating / authenticating the return
path. As far as I can tell, we have:
(i) Techniques for validating the authorization of a
particular sender to send mail using a given submission
server. The return paths are not validated and use by
an sender who is authorized to use a particular
submission server of an inappropriate backward-pointed
address is dealt with administratively (including, but
not restricted, to legal proceedings) if at all. A
special subset of these techniques does not depend on
mail processing at all but on the mechanisms, such as an
authenticated tunnel, to reach a submission server that
is not otherwise accessible.
(ii) Techniques for validating the relationship between
a backward-pointed address and a particular domain.
Those techniques may or may not involve any element of
sender authorization. And some of them are better
suited to evaluation of the likelihood that the message
is bogus by the receiver, rather than for rejection of
the mail by a relay MTA.
(iii) Techniques for validating the domain of the
backward-pointing address, but not specific addresses or
the binding between address and sender or user (note
that, as RFC 822 and its successors point out, these can
be different). Most of these are more useful for
receiver assessment than than are for accepting/
rejecting mail, at least IMO.
(iv) In theory, (i) could be combined with validation of
a specific list of addresses which a particular sender
is permitted to use in backward-pointed addresses in
both envelope and headers. In practice, other than
intra-enterprise in a few cases, I don't believe this is
regularly done in a sophisticated way. I have seen it
done by imposing a rule that one is only permitted to
send mail from a specific ISP-allocated address, but
that mechanism --while it reduces spam and spoofing-- is
not good for the notion that people should be able to
link email addresses to identities, independent of the
particular ISP to which they are connected, if they want
to do so.
All of this goes far beyond today's 2821 and 2821bis: as far as
they are concerned, these are administrative procedures, not
parts of the protocol. More important, I think it would be
unwise for us to change 2821 in a way that seemed to favor one
of these approaches over another or to pretend that one
dominated the others in terms of current practice.
In any case, I think it is very important, IMO, that the
strong point that the reverse-path MUST be valid before it can
serve any usefulness is stated, and that is how this is done
is out of scope.
I think it is hard to argue that the "MUST" in your sentence
above is a 2821 problem or that it represents current practice,
rather than a preference (however important), and that there are
important questions about what is meant by validity. As soon as
"validity" gets over into "authorization to use", one may be
dealing with issues that cannot possibly be validated by a
protocol.
Why -1?
The problem with your 3463-like suggestion is that it creates
the dilemma and question of "WHEN" should the reverse-path be
considered valid?
The specification mandates a MUST for reverse-path validity.
CAN-SPAM also mandates it as well.
IANL and your mileage/ interpretation may differ, but I don't
believe that CAN-SPAM mandates any such thing. What CAN-SPAM
mandates is that the sender address must be available and
actually reach the sender (or message originator -- it is
ambiguous about that too if we accept our understanding of those
terms). I think all of its requirements could be met with a
valid header "From:" field and a completely bogus return-path
and maybe vice versa.
So the question is?
When is the VALIDITY of the reverse-path important?
At the moment it is presented? or
At the moment it is required to be used - a BOUNCE action?
The latter is what 3463 may imply and create a design model
using this concept - which in my view is not quite safe in
today's world.
Of course. If someone is trying to subvert the system, there
are race conditions involved that are easily manipulated. But
I don't see what 2821bis could say about this even if we were so
inclined.
john