On Jul 30, 2004, at 2:35 AM, Douglas Otis wrote:
The message is accepted by the Sender-ID check with some rating other
than Fail, but a more complete check of the local part of the address is
done 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?
Yes.
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.
This must have been a conversation off this list. The bounce does not
happen for some mystical reason. The flaw, if you wish to call it that,
is that Sender-ID does not prevent the bounce spam/virus traffic as did
SPF. I strongly feel the motivation for publishing SPF was to find relief
from this bounce traffic. That relief is not available with Sender-ID.
The situation that creates the bounce is not uncommon. If mail is being
relayed, it is often the relay only checks the right hand side of the
recipient address. At some hop later, the local part of the recipient
address is checked. At this point, the message may get bounced. Spammers
are proficient at finding these configurations and using them in the
manner descibed. It is also common for a virus check to happen after the
message had been accepted, with a similar result.
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.
Sorry, I found Rand Wacker able to understand these concerns and continued
to express what seems to be philosophical differences separating what
appears to be rather common agreement on most issues. This statement does
not dismiss the initial concern, as you appear to have concluded. Sorry,
I'll restrain myself to smaller aspects of these details.
-Doug