On Jul 30, 2004, at 2:35 AM, Douglas Otis wrote:
The message is accepted by the Sender-ID check with some rating other
Fail, but a more complete check of the local part of the address is
subsequent to acceptance. This name check fails, as intended, and the
message is bounced. The same could happen with a virus.
So you are explaining that a bounce occurs because something other than
Sender-ID has happened, and therefore that is a problem with Sender-ID?
And this is NOT the ralph, fred, bob scenario you started with. So
we are back to receiving a bounce out of the wild, blue yonder?
I had never used these names? Sender-ID never checks the RFC 2821 MAIL
Ryan came up with the names after you backed into the use case when I
asked why it was there was a bounce in the first place. You said there
was a bounce because the mail was relayed to an MTA with the list of
valid users. Now you are back to the first use case saying that the
bounce just happens for some mystical reason. Ok fine. But then that
is not a flaw in Sender-ID, which is where this thread started.
On Jul 30, 2004, at 12:13 AM, Douglas Otis wrote:
To fully understand the scope of the problem, work only on what can be
assured. Limit the reach to the most immediate with simple measures
stop trying to indirectly authenticate the user. SMTP was never
intended to preform this function. BATV and CSV can make a dramatic
change without breaking mail, and can be put into play quickly. We can
make a real difference, if to recognize what is within our grasp, and
what is not.
When you started this thread, I thought you were suggesting you had
found a flaw in the PRA algorithm. That is why I engaged in
discussion. Instead, this thread seems to have backed into the
relative comparisons of CSV vs. SPF vs. Sender-ID, ground this working
group has been over many, many times. It is nothing new to find out
that one proposal deals with forwarding better, one proposal deals with
bounces better, and one proposal deal with phishing better.