|
Re: [Asrg] Unintended consequence of SPF
2006-03-17 13:19:36
On Mar 17, 2006, at 10:16 AM, John Levine wrote:
There are plenty of systems that do SPF checks against the From:
header. MSN/Hotmail, for example, will file a message in the junk
folder if the RFC822 From header gets an SPF fail (fortunately the
Sender: header is checked preferentially).
That's called Sender-ID. People in the SPF community assure me
that the difference is very, VERY, VERY important.
While the difference between SPF/Sender-ID is important, it may not
be discernible by examining the SPF scripts. When SPF qualifies the
return-path, a failure may be indicative of a Mediator, rather than a
MSA known by the email-address domain. The message may still be
valid for many reasons, but such failure is not readily corrected.
In the case of a sender acting on behalf of an individual that
directs DSNs back to the individual, this works without a problem
until the message is accepted and then rejected. With DKIM making
declarations that all messages are signed, BATV offers a compatible
solution to counter any DSN exploit. Conventions that do not return
the message content in the DSN should also discourage this exploit as
well. Sender-ID uses the _same_ SPF scripts to also qualify a header
field deemed representative of the latest sender. The selection
process anticipates a violation of RFC2822 with respect to the
inclusion of Resent-From header fields.
RFC2822:
,----
|Resent fields are used to identify a message as having been
|reintroduced into the transport system by a user.
|...
|
|Note: Reintroducing a message into the transport system and using
|resent fields is a different operation from "forwarding".
|"Forwarding" has two meanings: One sense of forwarding is that a mail
|reading program can be told by a user to forward a copy of a message
|to another person, making the forwarded message the body of the new
|message. A forwarded message in this sense does not appear to have
|come from the original sender, but is an entirely new message from
|the forwarder of the message. On the other hand, forwarding is also
|used to mean when a mail transport program gets a message and
|forwards it on to a different destination for final delivery. Resent
|header fields are _not_ intended for use with either type of
|forwarding.
'___
For each domain-name qualified using SPF in the message, 100 DNS
transactions can be directed to a victim domain by each Mail Handling
System in the path of the message. Each MHS that evaluates messages
using SPF foster a potential hazard that can not be mitigated without
blocking SPF records. While SSP walking up DNS label trees represent
less of a hazard, it adds to an already high overhead incurred
verifying the signature for substantially little benefit. Even Mike
said that Cisco annotates messages. When messages are annotated,
there is no need for SSP. SSP should not be seen as an anti-spam
measure and annotation makes the anti-spoofing property of SSP
redundant.
The value, if there is any, would be in modifying the handling of
messages that fall into exceptional cases. This could condition the
use of white-lists, delayed acceptance, and partial vetting of the
message prior to acceptance, for example. Before committing
resources, being able to quickly resolve which DNS is associated with
the sending system provides greater information about the sender than
investigating an IP address or domain-name in isolation. The easiest
way this can be accomplished is by an SRV record verifying the EHLO.
Once the EHLO is verified, defining paths for DKIM, the PRA, the
MailFrom would be a simple matter of going to that domain and
requesting a PTR list of acceptable EHLO parent domains. By using
special domain labels "*." for open-ended and "." for no additional
member (closed-ended) set, the following convention could replace
both SPF and SSP. This removes the potential for hundreds of DNS
transactions with network amplification problem to a single DNS
transaction:
_client._smtp.mx1.example.com. IN SRV 1 2 1 mx1.example.com.
; verifies the mx1.example.com EHLO
_oa._smtp.alumni.example.edu. IN PTR *.
; we don't offer outbound smtp services
_oa._smtp.example.biz. IN PTR .
; no other domain is used to send our mail
_mf._smtp.example.net. IN PTR example.com.
_mf._smtp.example.net. IN PTR *.
; we use example.com and others to send our mail
_dkim._smtp.example.gov. IN PTR example.com.
_dkim._smtp.example.gov. IN PTR example.net.
; these domains also send our signed messages
"_oa" stands for originating address which should encompass all
headers utilized by the PRA algorithm and in most cases only this
list should be needed. When there is a failure, the optional
specific identity lists (_mf, or _dkim) could be queried for possible
exceptions. This sole resource used by subsequent MHS would only be
made following verification of the MTA EHLO, a method that does not
cause network amplification. The reason for these lists is to help
in deciding the resource priority assigned to the message. Whether
the message is accepted immediately, or delayed could easily make the
difference between a block-list having timely information about the
particular sender or not.
This strategy should also permit the safe use of white-lists with
DKIM signatures, as this permits exceptional handling for messages
that might be an abusive replay. Once annotation is assumed, there
should be no reason to search for DKIM policies. Including policy
directly within the message and caching this information could be a
reasonable alternative. Those messages that can not be associated
don't get the smiley face annotation. There is a greater need to
indicate which keys within a domain are being used by trustworthy
sources, which can be done with a simple tag in the key or a selector
naming convention.
-Doug
_______________________________________________
Asrg mailing list
Asrg(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/asrg
|
|