Hi all,
I'm currently extending Courier::Filter[1]'s SPF filter module[2] to
support outbound checking. (See the end of the message if you don't know
what outbound SPF checking is about.) Even though Courier::Filter is a
plugin specific to the Courier MTA, my question applies to outbound SPF
filters in general.
For purposes of classic inbound checking, the module supports the
following configuration options:
* trusted_forwarders:
Should the spf.trusted-forwarder.org whitelist be used?
* fallback_guess:
Should a "a/24 mx/24 ptr" fallback policy be used for domains without
explicit policy?
* default_response:
A default response string for domains without explicit explanation
string.
My current plan is to simply introduce another option, called "polarity"
or something, which shall determine whether inbound or outbound checking
(or both?) should be performed by the filter module.
I'm now wondering whether the other options would be meaningful and useful
under outbound checking as well.
"trusted_forwarders" would theoretically be useful for trusted forwarders
who cannot yet perform sender rewriting (SRS or similar). When receiving
a message that is to be forwarded, the forwarder could see whether he is
considered a "trusted forwarder". But it still wouldn't be guaranteed
that the final recipient uses the t-f whitelist, so the forwarder can't
really rely on his outbound check if it just passed due to him being
listed on the t-f whitelist.
"fallback_guess" would theoretically be useful for sender domains without
explicit policy, just like with inbound checking. But like with
"trusted_forwarders", this is a receiver-side policy and cannot be
reliably assumed to be applied by the final recipient.
"default_response" would probably be useful for sender domains without
explicit explanation string, but any non-default explanations provided by
3rd-party domains might confuse the user because when submitting the
message he really is just dealing with the relayer (who is running
Courier::Filter), not with the 3rd-party whose domain he is using as
sender address. The relayer would probably better supply his own
explanation to the user in all cases.
So the "trusted_forwarders" and "fallback_guess" options would be
basically useless for outbound SPF checking, and the "default_response"
might have some use but wouldn't really be required.
Do you agree with my assessment?
References:
1. http://search.cpan.org/dist/Courier-Filter
2. http://search.cpan.org/dist/Courier-Filter/lib/Courier/Filter/Module/SPF.pm
--------------------------------------------------------------------------
A quick explanation of outbound SPF checking:
Outbound SPF checking is sort of a sender-side anti-forgery measure.
An outbound SPF check is performed by an MSA when an (authenticated) user
submits a message for relaying. Consider I am me.com.
Inbound checking:
| HELO caller.com
| MAIL FROM: <user@caller.com>
| RCPT TO: <user@me.com>
I check the caller's IP address against the "caller.com" SPF record.
Outbound checking:
| HELO user.isp.com
| AUTH ...
| MAIL FROM: <user@me.com>
| RCPT TO: <user@recipient.com>
I check my own (my MTA's) IP address against the "me.com" SPF record to
see whether the "recipient.com" MX would accept the message when relayed
by me, if it would do an SPF check. It is most useful if the user tries
to send with a 3rd-party sender address, for example:
| HELO user.isp.com
| AUTH ...
| MAIL FROM: <user@isp.com>
| RCPT TO: <user@recipient.com>
Here I'd check my own IP address against the "isp.com" SPF record to see
whether isp.com has authorized me to send (relay) messages with a sender
in the "isp.com" domain.
-------
To unsubscribe, change your address, or temporarily deactivate your subscription,
please go to http://v2.listbox.com/member/?listname=spf-devel@v2.listbox.com
I'm currently extending Courier::Filter[1]'s SPF filter module[2] to
support outbound checking. (See the end of the message if you don't know
what outbound SPF checking is about.) Even though Courier::Filter is a
plugin specific to the Courier MTA, my question applies to outbound SPF
filters in general.
For purposes of classic inbound checking, the module supports the
following configuration options:
* trusted_forwarders:
Should the spf.trusted-forwarder.org whitelist be used?
* fallback_guess:
Should a "a/24 mx/24 ptr" fallback policy be used for domains without
explicit policy?
* default_response:
A default response string for domains without explicit explanation
string.
My current plan is to simply introduce another option, called "polarity"
or something, which shall determine whether inbound or outbound checking
(or both?) should be performed by the filter module.
I'm now wondering whether the other options would be meaningful and useful
under outbound checking as well.
"trusted_forwarders" would theoretically be useful for trusted forwarders
who cannot yet perform sender rewriting (SRS or similar). When receiving
a message that is to be forwarded, the forwarder could see whether he is
considered a "trusted forwarder". But it still wouldn't be guaranteed
that the final recipient uses the t-f whitelist, so the forwarder can't
really rely on his outbound check if it just passed due to him being
listed on the t-f whitelist.
"fallback_guess" would theoretically be useful for sender domains without
explicit policy, just like with inbound checking. But like with
"trusted_forwarders", this is a receiver-side policy and cannot be
reliably assumed to be applied by the final recipient.
"default_response" would probably be useful for sender domains without
explicit explanation string, but any non-default explanations provided by
3rd-party domains might confuse the user because when submitting the
message he really is just dealing with the relayer (who is running
Courier::Filter), not with the 3rd-party whose domain he is using as
sender address. The relayer would probably better supply his own
explanation to the user in all cases.
So the "trusted_forwarders" and "fallback_guess" options would be
basically useless for outbound SPF checking, and the "default_response"
might have some use but wouldn't really be required.
Do you agree with my assessment?
References:
1. http://search.cpan.org/dist/Courier-Filter
2. http://search.cpan.org/dist/Courier-Filter/lib/Courier/Filter/Module/SPF.pm
--------------------------------------------------------------------------
A quick explanation of outbound SPF checking:
Outbound SPF checking is sort of a sender-side anti-forgery measure.
An outbound SPF check is performed by an MSA when an (authenticated) user
submits a message for relaying. Consider I am me.com.
Inbound checking:
| HELO caller.com
| MAIL FROM: <user@caller.com>
| RCPT TO: <user@me.com>
I check the caller's IP address against the "caller.com" SPF record.
Outbound checking:
| HELO user.isp.com
| AUTH ...
| MAIL FROM: <user@me.com>
| RCPT TO: <user@recipient.com>
I check my own (my MTA's) IP address against the "me.com" SPF record to
see whether the "recipient.com" MX would accept the message when relayed
by me, if it would do an SPF check. It is most useful if the user tries
to send with a 3rd-party sender address, for example:
| HELO user.isp.com
| AUTH ...
| MAIL FROM: <user@isp.com>
| RCPT TO: <user@recipient.com>
Here I'd check my own IP address against the "isp.com" SPF record to see
whether isp.com has authorized me to send (relay) messages with a sender
in the "isp.com" domain.
-------
To unsubscribe, change your address, or temporarily deactivate your subscription,
please go to http://v2.listbox.com/member/?listname=spf-devel@v2.listbox.com