On Fri, 28 Jul 2006, Jim Fenton wrote:
william(at)elan.net wrote:
On Fri, 28 Jul 2006, Stephen Farrell wrote:
A similar question to the previous one.
Current proposals involve searching for SSP stuff based on
the domain part of an unsigned message's RFC2822.From element.
Are there any other requirements there or is that the only
basis on which we need to be able to search for SSP stuff?
You need to be open to other possibilities and make system easily
extendeable to other identities. My preference would be to encode
identity in the lookup path, so instead of doing lookup on _policy
it would actually be done against _from._policy indicating that
this is record for From header field use policy.
How do you then decide which policies to check?
Decision on which policies to check is the same as which DNSBL to use -
in other words its up to the receiver to decide what it is going to do
(or if it going to use mail signatures for its decisions at all).
Does this mean that you
need to check every address corresponding to a From, Sender,
Resent-from, Resent-sender, 2821 envelope-from, and List-id, for every
message you receive, just in case there's SSP data in any of those
places? This sounds like a really onerous requirement.
[you forgot "Reply-To"]
And with 3/4th or more of emails there is no issue. For others there maybe
additional identities of interest depending on what classification system
is to be used but its actually not quite as bad as that you check every
domain of every header field because in reality number of identities is
small and they are compound and produce one address (i.e. originator
is compound of Sender/From, reply address is compound of Reply-To/From,
etc). I'm not against you only doing it only for From (how is that doing
with multiple addresses in From being possible btw) for now but the record
syntax and dns should be capable of being extended.
P.S. When was the last time you did ethereal to see what your anti-spam
software is doing?
--
William Leibzon
Elan Networks
william(_at_)elan(_dot_)net
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html