You should include PTR scope and checking. This is likely to be what
can cause the most damage to spammer's zombie armies if ISP begin
to use it.
It is also a lot easier to whitelist forwarder this way and offers less
chance of allowing spammer to get away then SUBMITTER that requires
lots of changes to email system (they might as well use SRS if they
are willing to change SMTP and deply submitter).
I'm kind of busy today so I'll comment more on Monday or weekend.
On Fri, 24 Sep 2004, Meng Weng Wong wrote:
I suggest that we proceed under the working assumption that
the patent apps do not in fact cover SPF Classic.
I propose that we focus on developing and refining Unified
SPF, with the following main points:
1) Receivers should check all three identities:
A) HELO hostname
B) MAIL FROM return-path
C) SUBMITTER if provided
D) if checking is done after the DATA command, the PRA
I say "three identities" because C and D are really the same
thing according to the SUBMITTER spec, yet SUBMITTER can be
treated as a first-class identity in its own right.
2) Reputation systems are to be an integral component of
Unified SPF. We define a positive result as "the
identity authenticates, AND the identity is recognized by
the receiver at the policy level". If any one of the
identities returns a positive result, we let the message
through. If none of the identities returns a positive
result, and an authentication or policy fail was detected
for any one of them, we reject. Otherwise, receiver
systems can proceed with the usual gauntlet of antispam
checks.
3) Forwarders are expected to send SUBMITTER if the
receiving system supports it, so they can pass test C.
Forwarders are also expected to put records on their HELO
hostnames so they can pass test A.
The above points have the following implications.
4) Receivers SHOULD support the SUBMITTER extension.
5) If (a receiver supports the SUBMITTER extension
AND none of the provided identities are recognized
)
THEN it MAY reject before DATA without examining PRA.
6) IF (a receiver supports the SUBMITTER extension
AND the sender sent a SUBMITTER value
AND the SUBMITTER value authenticates correctly with PASS
AND the receiver recognizes the SUBMITTER (at the policy level)
)
THEN it SHOULD accept the message.
7) IF (a receiver supports the SUBMITTER extension
AND the sender sent a SUBMITTER value
AND the SUBMITTER value does not return an authentication PASS
)
THEN it SHOULD reject the message.
I obviously haven't enumerated all the cases, so please
ask... I basically want to see a world where we respect the
SPF Classic auth rejections, but where we can "whitelist"
forwarders easily by HELO or by SUBMITTER, thus reducing the
need for SRS.
I have a prototype reputation system up and running so
punting tough questions in that direction is actually
allowed by the rules now.
-------
Sender Policy Framework: http://spf.pobox.com/
Archives at http://archives.listbox.com/spf-discuss/current/
http://www.InboxEvent.com/?s=d --- Inbox Event Nov 17-19 in Atlanta features
SPF and Sender ID.
To unsubscribe, change your address, or temporarily deactivate your
subscription,
please go to
http://v2.listbox.com/member/?listname=spf-discuss(_at_)v2(_dot_)listbox(_dot_)com