On Thu, 31 Jan 2008, Alessandro Vesely wrote:
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 most courteous thing a forwarder could afford to do in a
backscatter-intolerant and SPF-using world, is to apply SRS when forwarding
mail that came in with an SPF-pass, and to rewrite the return-path of all
other mail to <>, indicating that it is non-bouncable since it might be
forged.
Such a forwarder won't mind if an email it SRSed gets rejected
in-transaction -- since it's obviously prepared to deal with a
post-transaction bounce, and internally generating a bounce is no harder. But
<> mails still must always go through to avoid Forwarding Problem B.
At the same time, exemptions from Forwarding Problem K are needed both for
the SRS mailstream and for the <> mailstream.
So we have a new color of list, one that implies that messages with nonnull
return paths may be treated normally except that IP-based karma is not
counted, and that messages with null return paths must always go through and
are also karma exempt.
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?
In traditional forwarding, the forwarder-to-recipient return-path obviously
varies with the sender-to-forwarder return path, since they are identical.
While you can easily whitelist any particular sender behind the forwarder,
you cannot whitelist the forwarding relationship as a whole.
In SRS forwarding, different sender-to-forwarder return paths also cause
different forwarder-to-recipient return paths, since information to recover
the former must be embedded in the latter.
It probably should not have to "always succeed". This is probably where
some site may want to impose additional restrictions, [...]
It's the initial AUTH command that always succeeds. However, SWK-SPF does
allow for a form of authentication failure, because AUTH= arguments that
claim SWKs to which the peer IP has no rights (according to SPF) will not be
honoured. They probably should cause 5xx on MAIL FROM:, although I've left
that undefined.
maybe 's/an forwarded/a forwarding/'. I would also mention Fred before
Ralph, so that the order matches the message path.
There are different orders in different examples.
1. Sarah -> Fred -> Ralph
2. Sarah -> Ralph !BOUNCE! -> Sarah
3. (unspecified) -> List -> Ralph
4. Sarah -> Ralph
5. Sarah -> List -> Fred -> Ralph !BOUNCE! -> Fred -> List
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
No undeployment of SWK-SPF is necessary. What I mean by shutdown is that
after Example.org tries to send a MAIL FROM: <> to Ralph, and it 5xxes, for
any reason, then Example.org starts 4xxing every attempt to send a message to
"Fred". This means no more deadletters will pile up until Example.org
confirms that Ralph's misconfiguration is fixed.
Ralph won't like that because his forwarding will be unusable. That's his
incentive to deploy SWK-SPF.
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.
The list example doesn't involve forwarding. SWK-SPF helps with the
forwarding problems but has other uses.
But anyways, the forwarder uses <> to indicate that the message is an
unbouncable hot potato. They want to wash their hands of it, and if they
can't they'll just shut down the forwarding.
The mailing list does use a bounce address, since if there is a delivery
problem, they'd want to log it.
---- Michael Deutschmann <michael(_at_)talamasca(_dot_)ocis(_dot_)net>
-------------------------------------------
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=92046215-dc9cba
Powered by Listbox: http://www.listbox.com