spf-discuss
[Top] [All Lists]

RE: [spf-discuss] solving the forwarding problem

2005-09-14 15:19:34
From: Alex van den Bogaerdt 
[mailto:alex(_at_)ergens(_dot_)op(_dot_)het(_dot_)net]
Sent: Wednesday, September 14, 2005 4:11 PM


On Wed, Sep 14, 2005 at 03:42:37PM -0500, Seth Goodman wrote:

If you send mail to such systems, it should be no
surprise that you may reject any replies.  In general, sending
mail to systems that can't send DSN's is not a good idea.

Now we're getting somewhere.

I know that, for whatever reason, I will not receive DSNs from "P".
This means I will never send mail to "P".

Now, I send mail to "F".  How should I know it will forward it to "P" ?

I don't, and I don't care.  What I do care about it that "F" uses
_my_ name as return address.  I carefully avoid a problem but that
user at "F" decides he knows better and uses my name to do whatever
he likes.

Again: I don't care if he forwards the message to "P". Just don't
do it in my name.

The situation with forwarders is not that different from back when not all
sites were reachable from all other sites.  Back then source routes were the
way the message path was tracked.  As the internet became more connected, it
was neither necessary to specify a routing path nor necessary for a DSN to
travel the outgoing message path in reverse.  Thus the demise of source
routes.  Once that happened, any system relaying or alias forwarding just
kept the same, single mailbox return-path, since they could send DSN's
directly.

Now, when you say, "just don't do it in my name", that presupposes a
particular meaning for the return-path.  If you believe your address in the
return-path means someone is sending something "in your name", then you
probably interpret return-path as the current message submitter.  While it
most often does mean that (single-hop deliveries), what it means above all
else is the address to send notifications of delivery problems.

In that case, someone passing on an incoming message as a relay or an alias
forward and keeping the return-path the same is appropriate, even though SPF
does not like it.  You originated a message and wanted any DSN's sent to
you, but for one reason or another, the message does not get delivered in
one hop.  You still want the DSN's to come back to your address, so the
relay and/or forwarding hops keep the return-path the same.  This is by
design, and it is how SMTP was intended to operate since the time that
source routes were deprecated.

As pointed out by others, SRS partially resurrects source routes.  Not all
of them, just the most recent hop and the original return-path.  This is one
part of SRS that I don't like.  It forces DSN's to go through an extra hop
instead of being delivered directly.  That is both unnecessary and contrary
to how SMTP is intended to operate.




The point is: forwarder-old-style is bad, even without SPF.

Sorry, this list is to discuss SPF, not to criticize RFC821 and 2821.

Wasn't it you that wrote

" Let's compare this as it is today, without SPF.  That's how 99.9% of
  the recipients operate, so it is what we have to compare any argument
  of loss of function.
"

?  If so then I'm sorry.

Yes, I did write that, and I believe you are using it out of context.  My
intention was to use how email operates today, without SPF, as the baseline
for comparison to any email authentication scheme.  Maybe I was out of line
suggesting that criticizing 821/2821 forwarding is off-topic for this list.
I'm not the list moderator so I should probably avoid saying things like
that.  What I was trying to communicate in the quotes above, if you read
them in the context I used them, is that alias forwarding is very entrenched
and its properties are part of any baseline that we should use for
comparison.

There are lots of things wrong with SMTP.  Alias forwarding is just one of
them.  However, I don't believe declaring alias forwarding, as it is
currently done, undesirable is really worth debating.  It's not great, but
it _is_ widely employed.  It doesn't really matter what we think of it.  Why
not recognize that as a part of SMTP that we wish weren't there, but is and
will continue to be?  I think that is better than constructing an argument
that alias forwarding is inherently bad and therefore it is reasonable to
break it.  The latter will get us nowhere, except to be members of a tiny
club that does SMTP "right" while the rest of the world continues as it has
been.

--

Seth Goodman

-------
Sender Policy Framework: http://spf.pobox.com/
Archives at http://archives.listbox.com/spf-discuss/current/
To unsubscribe, change your address, or temporarily deactivate your 
subscription, 
please go to 
http://v2.listbox.com/member/?listname=spf-discuss(_at_)v2(_dot_)listbox(_dot_)com

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