Le vendredi 30 Juillet 2004 02:09, Douglas Otis a écrit :
Not everyone uses a null RFC 2821 MAIL FROM when they bounce.
Determining a bounce then requires RFC 2822 checks of the From or Subject
headers. This is not a solid basis for rejecting a message however. The
act of the bounce is best known by the sender, in this case.
What about the following idea :
- Suppose that our outgoing SMTP servers encode _all_ of their outgoing
MAIL FROM with SRS, whether or not the message is a forward, and whether
or not it initially comes from our own domain.
As SRS replaces the domain to match the forwarding SPF environment, the
return path attempts to colapse to two steps of this process. If a
forwarding process does not perform this function, then the message is
rejected, as now the SPF environment is wrong.
Rather than rewriting the return path, the concept is to use a public key
found with DNS of the originating domain. If verified to be of that
domain by the receiver, then the SPF environment check is not needed to
validate the return path before a bounce. If the encoding is recognized,
such a check could be used to discard a bounce by the receiver. This
would not allow a rejection of a replay message by the receiver however,
but then would not require 100% compliance for this to work through other
hops.
- Now we can reject all "bounces" (MAIL FROM: <>) that we would receive,
which RCPT TO: wouldn't be a valid SRS address.
Because if this were a legit bounce, then it would be a reply to one of
our own messages, and would thus go to a valid SRS address.
BATV always allowed that. There are virus filtering programs and other
noncompliant applications that attempt to "bounce" with a non-null return
path. If there were an encoding of the return path that could be
recognized and checked before the bounce were allowed, the sending side
would then be helpful getting rid of that class of traffic.
Not overly fond of SPF restricting user domains, I would rather see a
comment tag added to a resent-from header that validated the forwarding
domain using the same technique, if to reestablish the SPF environment.
This would be done, rather than placing this forwarding domain into either
the domain or localpart of the return path. This would forgive domains
not publishing SPF records or adding SRS, unlike SRS. As often said, I
think something like Identified Internet Mail would be a better choice for
identifying the user.
-Doug