----- Original Message -----
From: "Douglas Otis" <dotis(_at_)mail-abuse(_dot_)org>
To: <spf-help(_at_)v2(_dot_)listbox(_dot_)com>
Cc: "IMB Recipient 1" <mspop3connector(_dot_)juan(_at_)equinoccio(_dot_)com>;
<ietf-mxcomp(_at_)imc(_dot_)org>
Sent: Wednesday, June 15, 2005 10:29 AM
Subject: Re: [spf-help] Re: SPF and SenderID
MS tried to pull the stunt that v=spf1 is by default a
part of PRA. This is a lie, the IESG knows that it's a
lie, so senderid-lyon-core-01 can never pass as an RfC.
Bye, Frank (Cc: mxcomp)
This advice is based upon a false impression that Microsoft waits for an
RFC before producing product. Recall draft-leach-cifs-v1-spec-02.txt?
Consider spf2.0/mfrom and _removing_ v=spf1 as the safe reaction to
Sender-ID.
-Doug
First, thanks for not writing a thesis on the subject.
Second..................
Oh stop it Doug.
Sender-ID will go down in the annals of computer history as yet another
PAYLOAD "Get Pass the Door" security exploit that Microsoft pushes upon the
industry in the name of non-existence "virtual email security innovation."
It does not qualify as part of the "Trust Worthy Initiative" and Gates will
put another foot in his mouth if he claims it is.
Sender-ID is an unreliable PAYLOAD protocol and this is NOT want the
industry is looking for. So you can keep down this ad-nausem path of
knocking SPF every which way but loose, those who support Sender-ID will
suffer scalarbility consequences of getting killed with higher bandwidth
payloads. Hackers will BLAST away higher payloads just to help create the
scale issues. Customers who "just do it" because its part of the MS package
will then begin to blame MS as to why they didn't concentrate on a TRANSPORT
solution BEFORE THE JUNK is transferred I predict corporate mal-practice
and negligence suits because MS was very aware of the consequences.
If our customers want it, they will have to add it via MAIL FILTER hooks. We
will not take responsibility for fuzzy 2822 mail analysis technique and we
will NOT de-emphasize the R&D required for 2821 methods. Our system is
nearly 90-98% spam proof purely based on 2821 transactions.
Do you really understand the issue? I really don't think you do. It is
quite simple. A SPF FAIL is a FAIL. PERIOD. SENDER-ID is saying to NOT
accept this response and to ACCEPT the PAYLOAD to do more checking on
INFORMATION that MAY NOT be there and if was, the end results can just be as
POOR in trust.
--
Hector Santos, Santronics Software, Inc.
http://www.santronics.com