On Jul 29, 2004, at 3:52 PM, Douglas Otis wrote:
If the bouncer has published their SPF record, then the bounce may
receive a Pass(+) rating. : (
This is getting repetitive. Why is it bouncing and not rejecting?
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.
No. Bounce traffic is from a third-party beyond the control of the MTA
receiving the bounce. This is not between related parties.
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. The bounced message will use this unchecked address to return the
message. This return path could point anywhere and thus the message would
appear out of the blue, as you would say, sporting a high rating. With
headers able to trump the bounce From, a filter may have greater
diffculty, as the PRA local part could be anything.
No. The Sender-ID rating system directs mail into different folders
(rat-holes), and leaves to the end-user the task of sorting and
It does? I'll admit that I'm juggling multiple working groups and
umpteen various drafts between them, so I could have missed it. But
where is that written?
When asked at the Open Group forum at Boston, during a presentation by
Microsoft, they claimed the only result of the Sender-ID check was to sort
mail into differing folders with their new Outlook. It does explain their
lack of concern about reusing a list not intended for this function, or
the lack of security of the channel. It does not abate the abuse, it
simply tries to sort it into folders.
The goal should be to have the message either rejected
outright or placed into the inbox. If there is a problem, it can be
discovered and resolved, at the expense of the sender.
So where does Step 6 fail on this?
You are referring to a process that selects the PRA? Sorry, but I fail to
see that as having much to do with the rejection of messages.
The Sender-ID approach seriously degrades reliability of mail in a
systemic fashion, and puts a much greater burden onto the recipient.
This is an unproven statement. Repeating it doesn't make it come true.
Filtering in general degrades the reliability of mail. If you have
experienced a failure of the mail reaching its destination without notice,
then you are likely the victim of a filter. This happens and I have been
forced to ask many times for an examination of the spam folder. Perhaps I
become sensitve to this problem. I don't see Sender-ID as a solution for
many reasons, but especially when it encorporates filtering, without
addressing the source of abuse.
It does not really stop phishing, bounces, or spoofing.
What new data do you have on this that can be added to past discussions
of what some MUA's do and do not display to the users?
It is not just a matter of what is displayed. There are areas where any
shared MTA becomes an ample opportunity. Any ISP that transparently
intercepts mail, will then place all their clients at risk of this
phishing or spoofing. These clients may also lose mail, if they are
unaware of this practice and close their lists. This intercept technique
does abate spam. As Sender-ID does not, don't ask to have this practice
stopped to allow a weak phishing claim. The bounce problem has nothing to
do with the display. I would much rather see something like Identified
Internet mail rather than Sender-ID for this type of function. There will
be fewer victims of fraud then.
It does not identify the domain responsible for the introduction of the
No, it identifies the domain which will undergo a forgery check, just
like CSV and SPF.
There is a difference. CSV uniquely identifies the sending domain
granting access. Sender-ID or SPF may identify a set of domains that may
have granted access. This is significant, when accreditation is
In the abusive case, all 3 do not identify the domain responsible for the
introduction of the abuse. A spammer need not have purchased a domain to
How does a spammer forge the hostname with CSV? How does CSV not identify
It does not allow a means to control such introduction.
What about SUBMITTER?
Submitter is about the same as PRA, assuming PRA gets checked.
It does break forwarding. It does break mail "exploders".
In some cases, yes. So does SPF. CSV doesn't.
It does cause users to change their mail address.
In cases where the user does not control the DNS, there may be no choice
but to change their RFC 2822 From to be accepted.
It does cause users to expose more of the mail addresses.
In the case of Submitter, the user may expose two addresses to accomplish
It does put mail and DNS at risk.
This is another unproven statement.
Yes, I have not proved this statement. I can do the calculations that
raise concerns. I call that risk. I have not seen any counter studies
either. "That would be bad" does not suggest this matter has been
reviewed to any degree.