Michael Deutschmann wrote:
Aside from being more fleshed out, one change is that I've removed the
whitelist probing feature I included in my last TENBOX/E proposal. While
it would be useful, I realized that the "whitelisting" needed by a
forwarder is different from that wanted by a mailing list, so rather than
add complexity to deal with the difference, I decided to leave that for a
further, layered protocol.
As I'm not well acquainted with TENBOX, I don't understand why an alias
expansion should differ from a list expansion, as far as whitelisting is
concerned. Although lists should be characterized properly, they share
various operative similarities with aliases.
The draft contains various interesting ideas and concepts, some of which I
had already read on this list, but assembled them in my head in a somewhat
different way (see mine of Wed, 23 Jan 2008 16:13:51 +0100 "[spf-discuss]
Re: Relay".) I'll post a hopefully better description of my view later
today, so we may check for similarities and differences.
Now for some comments on the draft.
Ideally, whitelists would be keyed based on the From: address in the
RFC822 headers of a mail.
I'm not sure if "ideally" means "if addresses were trustworthy". IMHO,
whitelisting should be based on a <forwarding host, envelope recipient>
pair. BTW, why do you mention rfc822 rather than rfc2822?
It is not possible to whitelist a forwarder, since the MAIL FROM:
varies with the original return path.
If it varied (e.g. according to SRS) then it would be possible to apply an
SPF check successfully. To what variations of the envelope sender do you
allude?
However, to make this safer, this document proposes the
registration of a special virtual SASL mechanism, which always
succeeds but serves to seal an agreement between client and server
that the AUTH= argument is to be interpreted this way.
It probably should not have to "always succeed". This is probably where
some site may want to impose additional restrictions, such as the
forwarder having registered, its helo name to match an SPF "pass" test or
whatever. A failure message should tell the specific requirements
(possibly referring to a suitable web page.)
"Fred", an forwarded pseudonym of Ralph, at <fred(_at_)example(_dot_)org>
maybe 's/an forwarded/a forwarding/'. I would also mention Fred before
Ralph, so that the order matches the message path.
Since they agree that such a shutdown would be a bad thing, they both
deploy SWK-SPF. On the hop to Ralph, the forwarded mail is sent with
null return path and using the forwarding input mailbox
(<fred(_at_)example(_dot_)net>) as the SWK.
This apparently implies that in order to shutdown the forwarding agreement
one of the host would have to un-deploy SWK-SPF. The target host cannot do
that, if it also has other recipients who use the same mechanism. This is
another case where the initial authentication should fail.
C:MAIL FROM: <> AUTH=fred(_at_)example(_dot_)org
[...]
C:MAIL FROM: <list-owner-ralph=example(_dot_)net(_at_)fourth(_dot_)example>
AUTH=list(_at_)fourth(_dot_)example
It is not clear how does the forwarder decide whether to send an empty
envelope return address as in the first example, rather than keep it as in
the list example.
-------------------------------------------
Sender Policy Framework: http://www.openspf.org
Archives: http://v2.listbox.com/member/archive/735/=now
RSS Feed: http://v2.listbox.com/member/archive/rss/735/
Modify Your Subscription:
http://v2.listbox.com/member/?member_id=2183229&id_secret=92043800-f19236
Powered by Listbox: http://www.listbox.com