spf-discuss
[Top] [All Lists]

RE: Re: RFC 2821 and responsibility for forwarding

2004-12-07 11:04:12
-----Original Message-----
From: owner-spf-discuss(_at_)v2(_dot_)listbox(_dot_)com
[mailto:owner-spf-discuss(_at_)v2(_dot_)listbox(_dot_)com]On Behalf Of 
Richard Bang
Sent: Tuesday, December 07, 2004 5:55 AM
To: spf-discuss(_at_)v2(_dot_)listbox(_dot_)com
Subject: RE: [spf-discuss] Re: RFC 2821 and responsibility for
forwarding


Hi,

By publishing SPF you are declaring that you want to change
the way the
world works, even though this particular change doesn't seem
necessary.
By issuing a 551 response to mail from you when you've
published an SPF
record, the forwarder can continue to operate as normal for
most people,
while still giving _you_ the address to which mail is being
forwarded
today. If you want to send your mail there directly, you can.

The optimum solution:

Forwarders don't, they simple tell the sender what address to use, the
sending MTA then uses the new address. If it cannot send, it
can bounce to
the author with a sensible message:

Mail from: me
Rcpt to: c(_at_)d
551 - Would forward try <a(_at_)b>
...
Mail from: me
Rctp to: a(_at_)b
550 mailbox xxxxxx
....
Message failed. Address a(_at_)b (redirected from c(_at_)d) failed due
to mailbox
xxxxx

Forwarders don't even have to transfer the mail, they just
have to tell the
orinal MTA where to send the message. Authors can tell
receipients (if they
care) why mail is not getting through. (I for one hate
getting a bounce for
an address for which I have no clue of why the message was
going there.)

It would take time for this to filter through the net and
during that time
we may get bad bounces etc. but that was the case with open
relays and that
situation is getting close to being closed.

The ideal solution is for one hop delivery. My MTA to your
MTA with no one
in the middle. To achieve that we need MTA's to act on "No
longer here, try
here" replies. The .foward files can be usd to supply this info.

That's a fabulous solution.  "Not here, try here instead" would require MTA's 
to be updated to
handle that, but would be great for distinction between forgery/forwarding 
distinction.

But what about the secondary MX situation where your secondary is your ISP (for 
when your link is
down) and so the forwarding info isn't known.

We could say "the ISP must know about your forwarding", but truthfully the ISP 
rarely even knows the
list of valid recipients, it just accepts *(_at_)example(_dot_)com

So then we would need to define some protocol where the destination MTA can 
call the source MTA with
a call back to say "that email you sent my direction, a(_at_)b(_dot_)com is not 
here, but is actually d(_at_)e(_dot_)com".

Problem is either:
1)  The source MTA needs to still have a copy of the message, so it can start 
again with the new
address
or
2)  The source MTA needs to accept the message from the refusing MTA (smells 
like an open relay
exploit, or it needs to somehow authenticate that it was the original source of 
the message, in
which case the sending MTA needs a weak version of (1) anyway)

For large production environments, (1) could be a problem, but maybe its just a 
cost they have to
realize (like SES).

Thoughts?

Terry Fielder
Manager Software Development and Deployment
Great Gulf Homes / Ashton Woods Homes
terry(_at_)greatgulfhomes(_dot_)com
Fax: (416) 441-9085


Then SPF will work for all, Christmas will come early, we all
get a bonus
and there will be world peace (well maybe one day) :).

Richard.


-------
Sender Policy Framework: http://spf.pobox.com/
Archives at http://archives.listbox.com/spf-discuss/current/
Read the whitepaper!  http://spf.pobox.com/whitepaper.pdf
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>