On Sat, Nov 11, 2006 at 12:09:42PM -0500, John A. Martin wrote:
Alex> 2) Indeed one should not perform SPF verification on
Alex> messages coming from a forwarder, unless this forwarder is
Alex> using a semi-transparent proxy mechanism such as postfix
Alex> has.
Hmm... I'm not sure what you are referring to here. Would you please
elaborate on the "semi-transparent proxy mechanism such as postfix
has"?
http://www.postfix.org/XCLIENT_README.html
Basically, the MX server forwards information to the next hop. This
next hop uses the information for SPF verification and decides if the
MX server should or should not accept the message.
Without such an extension, the next hop would not be able to perform
SPF verification, as the incoming IP address most likely is not authorized
to send mail on behalf of the sender's domain.
Perhaps I should have said "transparent proxy". Whatever.
Example:
example.com is SPF protected, "v=spf1 ip4:192.0.2.1 -all"
A receiver's MX server has address 192.0.2.2 and internally forwards
mail to 192.0.2.3
192.0.2.1 sends to 192.0.2.2, using MAIL FROM:<user(_at_)example(_dot_)com>
So far so good. 192.0.2.1 is authorized. But then 192.0.2.2 is
going to relay this message to 192.0.2.3
Without this extension:
192.0.2.2 sets up a connection to 192.0.2.3, MAIL
FROM:<user(_at_)example(_dot_)com>
192.0.2.3 calls spf(example.com, 192.0.2.2) resulting in FAIL
Using this extension:
192.0.2.2 sets up a connection to 192.0.2.3, any MAIL FROM
using XCLIENT name=user(_at_)example(_dot_)com ADDR=192.0.2.1
192.0.2.3 calls spf(example.com, 192.0.2.1) resulting in PASS
Alex
-------
Sender Policy Framework: http://www.openspf.org/
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/?list_id=735