At 11:20 PM 6/20/2005 +0200, Frank Ellermann wrote:
Alex van den Bogaerdt wrote:
> So it isn't perfect.
Defining "not perfect" as superset of "FUBAR", yes.
> trust.example allowed a certain host to use its name.
No, it allowed to use its MAIL FROM, and it even knows that
this host checks it (SMTP AUTH + enforced submission rights).
> at least now you know it came from a host related (however
> loosly) to trust.example
In other words you got the bogus PRA-PASS for trust.examle,
it was a phish / spam / malware, and trust.example is added
to every RHSBL of the planet as a "black hat".
The victim of this phish / spam / malware will sue them and
maybe win. There is no relationship between PRA and MFROM,
it just doesn't work. The most fatal flaw of this scheme
is that it _apparently_ works in many cases. Nobody would
fix it only for trust.example, they are "collateral damage".
It would help if someone could provide a clear, concise statement of the
PRA/SPF problem and post it on the new website. I'll help with the wording
to make sure it is clear to non-experts.
See http://mipassoc.org/csv/CSV-Comparison.html for an example of clear,
concise, and unemotional criticism. The one place where the CSV statement
*isn't* clear, unfortunately, is the confusion over SPF record
interpretation. Under "Clarity and Safety" the statement is " ... there is
even some question about the ways in which SPF and Sender-ID records are
interpreted. Such confusion defeats interoperation and reliable email
delivery."
It's taken as a hit to both SPF and SID. At least that seems to be the
view of the CSV crowd.
--
Dave
************************************************************ *
* David MacQuigg, PhD email: david_macquigg at yahoo.com * *
* IC Design Engineer phone: USA 520-721-4583 * * *
* Analog Design Methodologies * * *
* 9320 East Mikelyn Lane * * *
* VRS Consulting, P.C. Tucson, Arizona 85710 *
************************************************************ *