Tony Hansen wrote:
However, I'd like to follow the lead of the 3463 reference found in
section 2.3.11, and suggest that some wording be added, probably to
section 3.6, along these lines:
This specification does not deal with the verification of return
paths for use in delivery notifications. Recent work, such as
[add REFERENCES here], has been done in providing ways to
ascertain that an address is valid or belongs to the person who
actually sent the message. A server MAY attempt to verify the return
path before using its address for delivery notifications, but
methods of doing so are not defined here nor is any particular
method recommended at this time.
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?
I suggested this type of insight for 28211bis in my very first input on
2821bis. I referred to the existing similar insight regarding the
reverse-path and forwarding path in section 3.3
3.3. Mail Transactions
..... Despite the apparent
scope of this requirement, there are circumstances in which the
acceptability of the reverse-path may not be determined until one or
more forward-paths (in RCPT commands) can be examined. In those
cases, the server MAY reasonably accept the reverse-path (with a 250
reply) and then report problems after the forward-paths are received
and examined. Normally, failures produce 550 or 553 replies.
Here we have two insights for validation; one for the forward-path and
one regarding the acceptability of the reverse-path.
Note, this does not imply validating the forward-path first should be
the only basis for accepting the reverse-path. It can also imply that
you may not wish to perform any overhead on checking the reverse-path
until you know there is going to be a payoff with a valid forward-path.
The latter is how we implement the concept to reduce return path
validation by 60% and I believe, others like Scott Kitterman who is
considering recommending this optimization concept for SPF as well.
The proof of concept is simple:
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.
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.
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.
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.
--
HLS