----- Original Message -----
From: "Radu Hociung" <radu(_at_)ohmi(_dot_)org>
Newsgroups: spf.-.sender.policy.framework.discussion
To: <spf-discuss(_at_)v2(_dot_)listbox(_dot_)com>
Sent: Monday, March 28, 2005 1:02 PM
Subject: Re: [spf-discuss] Modifications to SPF for Mask function
Why do you make the assumption that anyone who checks PRA will also
check
SPF?
Because it's only reasonable that SPF be used to reject the obvious
(forged) SPAM before DATA, and the non-envelope-forged phishing attacks
after DATA. I see no value in accepting a forged envelope, just to do
header checks on the forgery.
Perhaps I don't understand spf2/pra/mfrom/etc well enough. I thought it
depends on SPF, but not that it replaces it.
You are correct, and I admire your persistence on the matter.
But here lies the philosophical conflicts between Developers and
Administrators you will realize (if not already) soon enough. The industry
is literally confused on where these email authentication solutions should
take place.
A dynamic vs. Post SMTP solution? or Both?
For most SMTP developers, the solution is more obvious - at SMTP.
Not for the administrators whose most probable control comes with post SMTP
scripts, sieve, perl or otherwise.
Over 60-80% of all transactions are problematic - it shouldn't take much to
realize that stronger SMTP transaction management is the name of the game.
There is still a responsibility when transactions are accepted. Poor post
SMTP analysis that might reach the same conclusions puts a lot of pressure
on the "Bounce or Bit-Bucket" decision.
Over 30 to 60% of the RCPT targets are bad, it shouldn't take much to
realized that delay (MAIL FROM or HELO) verifications is a requirement, no
longer a recommendation today.
So on, and so on.
Sincerely,
Hector Santos, CTO
Santronics Software, Inc.
http://www.santronics.com
305-431-2846 Cell
305-248-3204 Office
http://www.winserver.com/wcsap (Wildcat! Sender Authentication Protocol)
http://www.winserver.com/spamstats (WcSAP Anti-Spam Stats)