At 13:19 20/07/2009 Monday, Hannah Schroeter wrote:
Hi!
On Fri, Jul 17, 2009 at 04:26:58AM -0700, Michael Deutschmann wrote:
[...]
So, I propose rectifying that in SPFv3. We just need to add a new macro
that expands to the RCPT TO domain of an attempted SMTP transaction. Might
as well add one for local-part, too.
*Which* RCPT to domain should it expand in this transaction:
HELO a.first.example.com
MAIL FROM: <user(_at_)first(_dot_)example(_dot_)com>
RCPT TO: <user1(_at_)second(_dot_)example(_dot_)com>
RCPT TO: <user2(_at_)third(_dot_)example(_dot_)com>
(Where the MX records for second and third point to the same machine so
the sending MTA delivers the mail to both recipients in the same
transaction...)
Kind regards,
Hannah.
i would assume the assumption is the spf would be being verified as standard
after each rcpt To: command is issued
{why spf looks currently only at helo and "mail from"}
{to return an accept or reject for that recipient depending on their
SPF/reject/ignore/tag policy+result}
but if spf is being checked elswhere {say after data} it would have to have
either to be decided by receivers implementation choice
hopefully no "wild" implementations leave it so late
but it does make forwarder mitigation via this macro potentially problematic
as a workaround it could be ONLY syntactically legal within an optional extra
include/exists
and that clients not fed {recomended extra} rcpt-to info would ignore such
optional extra includes/exists
and if such clients are end destination of forwarders hope they properly
whitelist their forwarders {as this feature won't be available for senders to
correct the error}
-------------------------------------------
Sender Policy Framework: http://www.openspf.org
Modify Your Subscription: http://www.listbox.com/member/
Archives: https://www.listbox.com/member/archive/735/=now
RSS Feed: https://www.listbox.com/member/archive/rss/735/
Powered by Listbox: http://www.listbox.com