ietf-mxcomp
[Top] [All Lists]

RE: Adoption of MARID, SPF and alternatives and thoughts on cost

2004-05-13 23:01:02

Neil Brown wrote:
people who think that MARID and/or SPF are cheap ways
to curb spam and/or phishing schemes are simply wrong.
It isn't that easy.
 
Michel Py wrote:
You missed my point: people will use MARID and SPF in any
way they see fit, not according to the way the IETF think
they should. This has been proven over and over.

Undoubtedly.
However, what people "see fit" will likely be influenced by
what they hear/read. If people hear "MARID and SPF can stop
spam", they are more likely to use it to try to stop spam
than if they hear "MARID/SPF gives useful weighting to spam
detection heuristics". Obviously the first is easier to say
and more attractive, so more people are likely to say it and
to listen to it.  But those who understand the realities
should make an effort not to make such untrue statements,
and to counter them when they are made.  That way
(hopefully) fewer people will make uninformed decisions.

This is all nice in theory, but does not work in practice. When MARID or
SPAM becomes a check box in a mainstream mail server or mail filtering
software, the person that checks the box and its options is generally
not capable of making an informed decision, the reason being (s)he never
read the manual not to mention that (s)he does not even know what "RFC"
means. 


nevertheless people that have chosen aggressive spam
filtering techniques will likely see it another way, which
is more black and white: fail = dump, anything else = process
through white/blacklists, heuristics, etc.

That is certainly their choice, hopefully with informed
consultation with their customer/clients/colleagues.

Who are no better qualified WRT making an educated decision and will
base their advice on things such as being burned trying, does it really
do something, how much memory and CPU does that thing gobble on my
server, etc. In theory, theory and practice are identical. In practice,
they're not.


I just think that the language used in public discussions
and especially in standards documents should make the
realities and the consequences clear.

No argument here. Just don't expect everyone that configures a mail
server to read them.

Michel.