----- Original Message -----
From: "Keith Moore" <moore(_at_)cs(_dot_)utk(_dot_)edu>
To: "Hector Santos" <winserver(_dot_)support(_at_)winserver(_dot_)com>
Cc: "Keith Moore" <moore(_at_)cs(_dot_)utk(_dot_)edu>; "IETF-SMTP"
<ietf-smtp(_at_)imc(_dot_)org>
Sent: Thursday, January 15, 2004 11:23 PM
Subject: Re: CBV systems - was Re: SMTP Extensions - proper reply code for
disabled commands
However messages with invalid return-paths *can* have a legitimate
purpose.
Keith,
I guess it is possible for one or more pieces of software use the same
weakness in the functional specs that spammers exploit for what is deemed
legitimate behavior. I don't wish to mis-understand you so correct me if I
am wrong. Are you stating this is considered normal, standard,
pseudo-standard, legacy or compliant behavior and therefore, proposals to
that remove this possibility ought not be considered?
An invalid return-path should have no effect at all when the message is
able to be successfully delivered.
Hence you are saying that validity is not in question until message can not
be delivered? Which is why I ask, when it is require to be valid? If you
consider bounce mail delivery is also part of the functional requirement it
has a major effect on the system.
Ok, so what if a DSN was going to be sent? A normal SMTP queuing
will occur.
If, once you've decided to bounce a message, you want to use CBV to
decide whether to deliver a DSN, feel free, though I don't really see
why you'd bother.
I was referring to a normal SMTP send mail process queuing outbound bounce
mail. The CBV is not going queue the attempt to validate a session return
path.
Good question. Some countermeasures are more easily circumvented than
others, so it might make sense to deploy mechanisms that aren't easily
circumvented.
Of course, anything that works better, is preferrable. Nonetheless, even
these implementations, if and when successful, it will considered wasteful
overhead.
Client/sender validation might well be a good idea. But we shouldn't
confuse that with return-path validation.
I poise the question again, What is the purpose of the return path? When it
is suppose to be valid or not? If you say it *may not* be valid, then that
should be written into functional specification. If you saying that for
legacy reasons, there might be situations where an invalid return path is
used for some kludge behavior, well, I don't think we can work on this basis
anymore. You can't have it both ways and expect auditing and tractable
solutions to be developed.
Section 3.3 makes it possible to perform return path validation;
3.3 Mail Transactions
...
The first step in the procedure is the MAIL command.
MAIL FROM:<reverse-path> [SP <mail-parameters> ] <CRLF>
.................................. If accepted, the SMTP server returns
a 250 OK reply. If the mailbox specification is not acceptable for
some reason, the server MUST return a reply indicating whether the
failure is permanent (i.e., will occur again if the client tries to
send the same address again) or temporary (i.e., the address might be
accepted if the client tries again later).
...............................................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.
I guess what needs to be defined is "acceptability."
--
Hector Santos, Santronics Software, Inc.
http://www.santronics.com