At 17:08 20/07/2009 Monday, Dotzero wrote:
On Mon, Jul 20, 2009 at 11:53 AM, alan<spfdiscuss(_at_)alandoherty(_dot_)net>
wrote:
but these issues only arise if the sender only publishes SPF and ignores
sender-id
{as sender-id checking clients will mis-use the SPF record in ONLY this case}
if we mandate the use of a {blank is enough} sender-id policy with SPF the
issue is no more
ie
for domain have
"v=spf1 redirect:_spf1.domain.tld"
"spf2.0/mfrom redirect:_senderid_mfrom.domain.tld"
"spf2.0/pra +all"
and have _spf1.domain.tld and _senderid_mfrom.domain.tld
return the same spf record
with appropriate "v=spf1 or "spf2.0/mfrom start
thus no crosstalk or conflict and issue resolved
but only if SPF group advises people to mitigate rather than ignore
sender-id will it go away till v3
Alan,
The issues I referred to are brokenness within Sender-ID, not abuse of
SPF1 records. One key brokenness in SID is the paragraph in RFC4407
that sates:
"3. Select all the non-empty Sender headers in the message. If there
are no such headers, continue with step 4. If there is exactly
one such header, proceed to step 5. If there is more than one
such header, proceed to step 6."
Giving precedence to the "Sender" field allows one to game the system
to get a neutral (at minimum) for what are clearly spam/fraudulent
messages.
i wasn't actually responding on the subject of sender-id's brokenness {further
than their mis-use of spf1 records}
as for those interested in SPF thats all that counts/matters and impacts users
of SPF
-------------------------------------------
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