On Thu, 2004-08-12 at 04:39, Mark Shewmaker wrote:
On Wed, 2004-08-11 at 13:03, Douglas Otis wrote:
A public list assessing these identities used to block mail would be
doomed. Abuse *beyond* the domain holder's control would elicit a legal
challenge to any assertion of their reputation that stops their mail.
Then people who live in jurisdictions where such is possible will
suffer, but that's no reason to make those who live in more civilized
parts of the world suffer along with them.
This does not provided the domain holder any alternative! They have
done nothing wrong, and yet a listing based upon Sender-ID claims they
did. As a result, their mail is stopped. What is fair or civilized
about that? These transparent interception techniques ARE civilized and
DO provide significant relief from the amount of abuse suffered upon the
world.
Sender-ID does NOT offer even a modicum of relief from spam nor enable
enforcement. The advocates of Sender-ID exclaim "It is not about
spam!" (This is coming from a group tasked to carry forward work of the
ASRG?) This is a puzzle. Sender-ID is not about accurately identifying
the sender either. Sender-ID does not stop phishing, spoofing or
curtailing spoof bounces. The discernible purpose is to disable outside
mail services, or, as claimed by Microsoft at the Open Group Forum,
Sender-ID is to increase the number of Outlook folders. : (
There would be no other recourse. There may be hundreds of such domains
sharing a transparent MTA imposed by their ISP. This convergence may
not be apparent to the recipient, but would allow any of these hundreds
of domains to assert any of these Mailbox Domains.
Obviously, domains whose outgoing MTA service is an MTA that allows
cross-customer forgeries will likely suffer in reputation.
Reputations based upon Sender-ID would never point to their servers as
being at fault. Here lies the rub. Sender-ID can not be trusted, and
yet the party at fault can not be identified.
That's quite as it should be, IMHO.
If you were not wishing to take any action against spam, perhaps.
If honest-company.com authorizes incompetent-isp.com to send mail on
their behalf, but incompetent-isp.com lets we-love-to-forge-emails.com
use their servers to forge emails in honest-company's name, well of
course honest-company's reputation will suffer.
Based upon which reputation service? These providers will spend their
scant time in court, if they were foolish enough to depend upon the
ability of Sender-ID identify miscreants.
That will happen now, just more indirectly, via IP-based block lists.
So you are advocating IP based blacklisting as the solution?
It can happen after SenderID becomes popular, (assuming people do
classicSPF tests to of course), via domain-based (and email based?)
block lists, for domains whose outgoing smtp services are hosted at ISPs
allowing cross-customer forgeries.
This sounds like mumble, hand-wave. Are you advocating to block all ISP
that take measures to control spam, in favor of this new goal of
restricting the use of RFC2822 From Mailbox Domains?
But it won't be such a concern for ISPs and other mail service providers
that don't allow cross-customer forwarding. So things are only
improving in that way.
You mean to enable spammers?
Also, how would you rate Mailbox Domains that resolve to being
valid, but are outside their prescribed Mail Channel?
I don't understand what you're trying to ask. I don't quite understand
the sentence.
Sender-ID allows 5 or 6 levels of acceptance. Sender-ID may validate
mail as being fully rated without having emerged from a prescribed set
of MTA clients. How does this mail get classified? Would you suggest
anyone using one of the Sender-ID options should have their mail
blocked? The contract provided by Microsoft specifically absolves them
from this type of harm. Who will find themselves in court then?
Or you could filter out PRAs with bad reputations--those appearing on
domain-based block lists.
A provider of these services would need to obtain a contract that
stipulates PRA identities will NOT be used in conjunction with their
listing services.
Why?
Sender-ID must not be trusted as explained. Expectations of a
reputation service used against the PRA will not provide satisfactory
results. In addition, complaints raised as a result must be ignored.
If to provide a reputation service, it must be made clear PRA is not a
valid basis for registering complaints nor blocking spam. Is there a
better way to make that point clear?
As one of your users have vouched for this sender, a
bounce should not be a problem, as this is not a bad actor.
I wouldn't assume the "not a bad actor" bit--we're talking about
potential attack vectors, so by definition we have to assume that anyone
could be a bad actor.
You have allowed a user to create a white-list. If you discover they
are white-listing an egregious spammer sending in bulk to non-existent
users in your domain, you may reconsider allowing this specific
white-listing or perhaps dropping this user. If these messages are to
valid users, then it does not sound like a typical spoof bounce attack.
It also appears they do not appear on an IP blacklist.
Imagine I were an ISP and a forger wanted to use my machine as a source
of bounce spams.
He could sign up an account "forger" on my machine, then from elsewhere
send the bounce spam to his new account and to another customer of
mine. As he white-lists himself, his own mail won't bounce because it's
sent to his account, (and he presumably forwards it somewhere else to be
sent to /dev/null there), but it does bounce when sent to the innocent
subscriber--and thus it gets bounced to the "victim" account.
I assume you are suggesting this spammer also knows valid accounts on
your system, but also knows that these other users will be rejecting
their message based upon a filtering result (not a blacklist).
Now the "victim" could be one of a number of targeted accounts--or it
could be one of a number of people known to immediately become incised
at bounce forgeries, such that that they quickly get my IPs put onto
blocklists before I realize what's going on.
Hence the need for BATV? As you said, this spammer may not cooperate by
using Submitter either. Submitter does not seem to offer any
"optimizations" nor does Sender-ID even inspect MAIL FROM.
Yeah. I'm wondering if, were any RFC to come out for an smtp extension
allowing per-recipient after-data rejects, if it would soon become
acceptable to give "too many recipient" errors on second and subsequent
recipients when the sending MTA (!) doesn't support such an extension.
Would the sender enumerate each recipient in some fashion to then allow
selective rejections?
"selective rejections"--I like that.
Possibly--for such an extension to work, the SMTP client would have to
let the server know that it understood the extension too, one way or
another.
Perhaps if, after the server said it supported selective rejectsions
after data, say by putting "SRAD" in the EHLO response, the client could
enable that behavior with a new "SRAD" command by itself, or perhaps
putting "SRAD" as argument to each and every RCPT command. (Though the
later seems wasteful to me.)
Fine.
I'm sure there's lots of ways this could be done--and it's by far a more
straightforward problem that SenderID.
Interestingly enough even if solving this problem were in-scope for this
group, so that the same RFC that published SUBMITTER also publishes an
after-data-selective-rejections extension, that's *almost* a no-op for
SenderID purposes. (!)
Clients and servers that supported SUBMITER would have no need for the
other extensino because of SenderID purposes, (though it would be
convenient for other types of recipient-settable after-data tests),
because they'd be using SUBMITTER anyway and thus allowing for
per-recipient *pre*-data rejects, which is what everyone wants in the
first place. (Well, everyone but forgers and the like.)
So, I'm guessing that if NO SUBMITTER == Pull-PRA-from-headers, that
smtp servers will simply have to allow only one recipient per
no-SUBMITTER message at some point. (Or perhaps more than one--up to
the first recipient with a different white list.)
Not fun.
Hence BATV?
That assumes there is a check made at this point. This is the great
downside when allowing Submitter. This check becomes optional and the
modicum of security goes out the window.
I don't see how the fact that it didn't bother to fill in some paperwork
mean that there's a security check.
The problem you seem to overlook is that the MUA does not see
Submitter.
If the standard allowed the sending MTA to just make up a SUBMITTER
without it being in the headers, the presumably it would also be changed
to allow the receiving MTA to add non-PRA SUBMITTERS to the headers as a
PRA. So IMHO, this specific security worry is more of a moot point--the
standard could be worded either way really.
The standard can not enforce what a miscreant does. The danger, as
stated, is that if only submitter were checked, it would not matter what
was contained within these headers and the user would be under the false
impression at least one of the headers had been checked. What had been
checked will remain a mystery.
-Doug