On Jul 30, 2004, at 7:02 AM, Andrew Newton wrote:
And this is NOT the ralph, fred, bob scenario you started with. So
now
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
FROM.
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
and
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.
Do we not want a solution that deals with each of these problems? I
would rather spend a few more months having to wait for an adequate
solution, rather than roll out a flawed solution and hope for the best.
What would be the problem with addressing these issues now? And that is
not a rhetorical question, I really want to know.
Thanks,
Ryan
--
Ryan Ordway
Sr. Unix Systems Administrator
rordway(_at_)once(_dot_)com