ietf-mxcomp
[Top] [All Lists]

RE: Does marid-submitter-02 really make sense?

2004-08-12 04:36:10

On Wed, 2004-08-11 at 13:03, Douglas Otis wrote:
On Tue, 2004-08-10 at 23:04, Mark Shewmaker wrote:
On Tue, 2004-08-10 at 14:34, Douglas Otis wrote:
On Tue, 2004-08-10 at 05:42, Mark Shewmaker wrote:
Sure you can--you can see if you have white-listed that PRA yourself, or
if your trusted friends have--thus giving you reason to believe claims
made by this PRA,

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.

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.

That's quite as it should be, IMHO.

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.

That will happen now, just more indirectly, via IP-based block lists. 
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.

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.

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.

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?

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.

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.

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.

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.)

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.

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.

-- 
Mark Shewmaker
mark(_at_)primefactor(_dot_)com