[Top] [All Lists]

Re: Recap Issues 0b/21/25

2007-04-29 20:34:40

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.


<Prev in Thread] Current Thread [Next in Thread>