<tv+spf(_at_)duh(_dot_)org> wrote:
Stopping forgery at the MAIL FROM sender level is pretty cut and dry. I
don't see how you could then additionally consider the mail to be a
"forgery". Exactly what additional information are you trying to check!?
At the current stage of SPF deployment and development, I see this
as a promising technology, but something still at the research
stage. I for one am not ready to patch the MTA for my stable
production server in such a manner that this may result in
unknown vulnerabilities, instabilities and false positives. When
the SPF patches have been sufficiently well tested to be adopted
into mainstream Sendmail or similar MTAs, and DNS administrators have
a better understanding of the pattern of legitimate mail origination
for their domains and use of the SPF record syntax etc. my
view on this is very likely to change.
Until then I am a lot more interested in seeing how effectively
SPF tagging pass/fail will be effective in supplementing current
methods of spam rejection, tagging and filtering, the
first stage of which (rejection prior to data) occurs at my MTA
(checking originating domains exist and using a couple of DNSBLs),
and the second stage occuring after the data phase (SpamAssassin and Tagspam,
the latter of which allows me manually to check my spam folder every
few days very quickly to check for false positives. Using Tagspam
to do DNSBL checks after delivery picks up the spam the neccessarily
more accepting secondary MX MTA (which I don't administrate)
allows through. I get about 30 - 40 good messages a day, and
reject about 300 a day at the MTA level and filter out about
another 70 spams a day at the secondary filtering stage.
About 10 spams a day make it into my inbox.
So at this stage I am not ready for any SPF based rejection at the MTA,
but want to do all of this through tagging and procmail rules,
based on later processing, allowing for occasional and quick
manual inspection of my spam folder .
I think there is also an advantage here, in the sense that I
think it probable that SPF
aware spammers will very soon learn how to automatically create
envelope headers that the receiving MTA expects. Forgery, as
I understand this, from
the end user point of view is then about what is in the From: data
header which controls the reply button, and not about what was
in the From envelope sender which most end users won't see in
any case. When reliable MTA rejection
and SPF filtering are both available, I feel a number of people
including myself are likely to want to do both. In the meantime
it would be useful for the standards documents to assist with
either approach, but neither should be mandated.
Richard Kay
-------
Sender Permitted From: http://spf.pobox.com/
Archives at http://archives.listbox.com/spf-discuss/current/
Latest draft at http://spf.pobox.com/draft-mengwong-spf-02.9.4.txt
To unsubscribe, change your address, or temporarily deactivate your
subscription,
please go to
http://v2.listbox.com/member/?listname(_at_)©#«Mo\¯HÝÜîU;±¤Ö¤Íµø?¡