----- Original Message -----
From: "Stuart D. Gathman" <stuart(_at_)bmsi(_dot_)com>
On Tue, 21 Jun 2005, Hector Santos wrote:
PRA is not a magic new "entity" in the system. It is just a terminology
for
checking existing headers, if any, at the payload.
True, but PRA is not a specific existing header - it is one of the
existing rfc822 headers selected according to a patented algorithm.
Isn't that same thing? 6 in 1, 1/2 dozen... :-)
SPF1 means checking MFROM.
Correct. (Except it can also check HELO.)
Its optional in SP1, so its better to leave the details out.
By stating they will not do a MFROM check, it could only mean they are
delaying the check until the payload is received. They will need to
check
for the Return-Path: which is the MFROM.
No, they do not check Return-Path. They check From:, Sender:, Reply-To:,
or one of the other rfc2822 headers selected according to their algorithm.
I don't believe Return-Path is selected by their algorithm.
Thats the problem!!! Thats my point. There is no guarantee that prior art
headers Sender:, Reply-To:, Resent-XXX will exist in the payload, so if Jeff
heard MS say "they will not check MFROM" then they are left to also
checking Return-Path: as well.
They are checking a COMPLETELY DIFFERENT identity than MFROM. Their
new identity might have some value, but it is not MFROM.
There is no new identity. If there are were a new identity in the picture
then:
a) The Patent has more validity, but still would be hard to enforce. But
more validity nonetheless.
b) It implies a new level of presumptions, operations and enforcement.
c) It helps in the "anti-spoofing" department.
I would prefer a new identity because this means that if its there, then you
know there is a implied assumption about the intention of the message. It
would be like you stamping the message with a special hash ID header to help
add some integrity to the message.
But it fail to do this. This is why the patent is weak and the algorythm is
poor as any other method simply because it relies on "pre-existing
conditions" that is part of the overall problem with the SMTP/2822 system.
It would be ideal to find a solution that works on pre-existing conditions
because that means widest adoption and lower barrier to acceptance. But
when we say Solution, we would like to think it would work, all the time.
It won't and because it doesn't work all time, SENDER-ID will add a new
level of industry bandwidth pressure because it encourages to look at a
payload that *may* not have the data you are looking for.
Look, when Harry at MS first proposed SenderID, I wanted to show him how it
won't work. So via Telnet, I went to Microsoft.COM and manually started a
SMTP session to send him a message. In the DATA part, all I wrote was:
HELO testmachine
MAIL FROM: <hector at santronics.com>
DATA <harry AT microsoft.com>
Hi Harry, look no headers!
.
The message was accepted and alittle later he sent me a reply.
"What was the meaning of this?"
I was floored that the guy didn't have a clue and I wrote back:
"It means most systems except DATA without the headers
you expect to be there."
He basically wrote back saying:
"Well, that's should not be happening..."
I guess he was thinking that under normal MAIL operations, you will have
headers in the message. Go figure.
The point is, the headers MAY not be there and if you are not checking the
MFROM at the 2821 level, SENDERID adds a tremendous amount of potential
payload waste.
Look, don't you think we studied this for our products? Don't you think
that it was worth the effort, we would do it? Why not? We are commercial
system? Why not join the ranks of the hype and say:
"Santronics now supports Sender-ID!"
No, because I have more integrity to do this. I have ethics and I am not
going to impose a poor concept on my customers.
Unfortunately, once MS releases it, soon enough we will have the layman
customer begin to ask "Hey, I see MS is using SenderID. Does Wildcat do
Sender-ID?" and at that point, I have to see what I can do to accommodate
them.
I already decide it will be part of the mail filter DATA hook system where
our 3rd party developers add their mail filter rules and logics. I need to
make sure I add and expose information to extract the PRA. Sort of like
giving them a Sieve Rule, but we don't use Sieve, we use a p-code compiled
BASIC language.
But this will not change the heavy emphasis on SMTP level checking. The
goal is reduce the payload, not increase it.
--
Hector Santos, Santronics Software, Inc.
http://www.santronics.com