spf-discuss
[Top] [All Lists]

RE: Ignoring rejected mail?

2004-12-08 12:26:35
-----Original Message-----
From: owner-spf-discuss(_at_)v2(_dot_)listbox(_dot_)com
[mailto:owner-spf-discuss(_at_)v2(_dot_)listbox(_dot_)com] On Behalf Of Stuart
D. Gathman
Sent: woensdag 8 december 2004 19:28
To: spf-discuss(_at_)v2(_dot_)listbox(_dot_)com
Subject: RE: [spf-discuss] Ignoring rejected mail?

On Wed, 8 Dec 2004, Mark wrote:

And as I have been replying ever-since: without the digest, there is
nothing SES offers which I cannot also accomplish with a 'self-signed'
SRS address. Including call-back verification.

The self-signed SRS is basically SES classic. Leave out the duplicate
source domain, and change the leader so as not to confuse software
that "unwraps" SRS, and you have SES classic.

Yes, Stuart, this is true. Hannah and I reached pretty much the same
conclusion, the other day. Those two forms really look remarkably akin. :)

The replay prevention on SRS is fine for forwarding and for rejecting
forged bounces. Replays will only annoy a single victim - not reach
a wide audience. However, SRS does *not* work for authentication.
If you use SRS for authentication, then I can use the signed MAIL FROM
you send me to spam the world while pretending to be you until time
limit expires (typically several days).

Mail::SRS::DB (MLDBM based Sender Rewriting Scheme) already creates unique
hashes for each and every encoded address. That could certainly be used
for (callback) authentication, because it has a 1:1 granularity, so to
speak.

Although part of the standard SRS distro, I have not implemented the DB
variant of SRS yet. I was, at the time, not clear on thread-safety
(re-entrant calls to DB_File); and I thought a database might not scale
all that well. Other than that, it can be done with SRS. :)

SES tries to fix that.

The first attempt to fix the reply attack was to add a message id to
the signature (not a digest) and limit the number of successful
validations per message. There is no need to track validation
failures. This is the approach I plan to use. The limitation is that
some recipients, like a large mailing list that doesn't rewrite MAIL
FROM, will have a large number of legitimate validations, whereas a
single recipient will only have a few (one, plus and forwarders that
check SPF). Pooh. Mailing lists *should* rewrite MAIL FROM, so I will
have a low validation limit. No database is required to track
successful validations. An in memory table suffices.

I have toyed with the idea of limiting callbacks, too; after all, as you
say, it is trivial to store the amount of verifications to a certain
address. I did not have enough data, however, to accurately
predict/anticipate how many of such legitimate calls would/could be made.
I eventually figured that, for me, there was no real benefit to limiting
the amount of CBV's, and that I was likely going to break something rather
than be helpful. I deemed it especially problematic if a user of mine were
to send to, say, 30 recipients; in that case, I could expect 30 callbacks
(or 30 DSN's, depending on what you count). I suppose I could use a
formula which takes the amount of recipients into account; but then I
figured those recipients could expand, via aliases, to multiple
recipients; and then I thought: never mind. :)

I agree with you that mailing list software should rewrite MAIL FROM. And
you are, imho, well within reason to count on them not to be broken in that
fashion.

... Part of the message digest is included in the
MAIL FROM signature in place of the message id,
so most forgeries are detected before SMTP DATA.

How can you check your digest against anything before the DATA is in?

If that passes, the message body is received,
and the full digest can be checked.

Do you mean to get the message header first? But that is also part of
DATA; and, unfortunately, there is no separate HEADER and BODY command
yet. So once you pull in the DATA, you need to swallow it whole. I would
be interested to hear how you do this 'shortcut' signature check.

Cheers,

- Mark 
 
        System Administrator Asarian-host.org
 
---
"If you were supposed to understand it,
we wouldn't call it code." - FedEx


<Prev in Thread] Current Thread [Next in Thread>