On Tue, 24 Jan 2006, paddy wrote:
couldn't help noticing at the top ...
From
listbox+trampoline+735+2169844+4bf648b9(_at_)v2(_dot_)listbox(_dot_)com
Mon Jan 23 23:28:31 2006
From: "Stuart D. Gathman" <stuart(_at_)bmsi(_dot_)com>
not sure if you'll care about this kind of thing for your application,
but it seems like the same sort of thing to me.
Good point. With that type of sig, I think the "bare" localpart to use
for whitelisting is the part before the first '+'. It shares this
with the sendmail "plussed users" feature.
If it is possible to stem a potential tide of random diverse re-inventions
by standardisation, then I don't see why that isn't a sufficient reason
to exist in its own right. The problem here would seem to be that maybe
the horse has already bolted ? All these things are not extensions so
much as local in-band encodings?
It doesn't really matter what the encoding is. All that matters
for interoperability is a way to extract a "fixed" localpart that
is significant for whitelisting. My system actually falls back to
an empty localpart, which effectively whitelists the entire domain.
Ideally though, I would want the list name to be extractable from a
mailing list sig, so that particular lists could be whitelisted.
I'm thinking that Julian is right, and a library that handles a bunch of
currently known schemes will at least encourage inventors of new
signatures to at least pick one of those as a starting point.
I'll add a module to pysrs or pymilter.
--
Stuart D. Gathman <stuart(_at_)bmsi(_dot_)com>
Business Management Systems Inc. Phone: 703 591-0911 Fax: 703 591-6154
"Confutatis maledictis, flamis acribus addictis" - background song for
a Microsoft sponsored "Where do you want to go from here?" commercial.
-------
Sender Policy Framework: http://www.openspf.org/
Archives at http://archives.listbox.com/spf-discuss/current/
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