On Fri, 13 Feb 2004, Greg Wooledge wrote:
Brian Candler (B(_dot_)Candler(_at_)pobox(_dot_)com) wrote:
(1) If the SPF proposal is widely adopted, I'd expect spammers just to start
sending spams with null envelope senders, i.e.
MAIL FROM:<>
RCPT TO:<me(_at_)mydomain(_dot_)com>
They already do. I'd like to stop this, and I think SRS can be used,
or tweaked, to do it.
The only solution I can see is the cryptographic signing of sender
addresses, for example in the way proposed in SRS, for *all* outgoing mails
(not just forwarded mails).
Yes, this is brilliant. Thank you! :) Here's what I'm thinking about
so far:
Normally, if I send a message from my own box (wooledge.org) to a
misspelled username on another domain:
wooledge.org
| MAIL FROM:<greg(_at_)wooledge(_dot_)org>
V RCPT TO:<misspelled(_at_)domain(_dot_)com>
mx.domain.com
then I get a bounce message. But *anyone* can send back a bounce message
to greg(_at_)wooledge(_dot_)org just by claiming to be a mailer-daemon:
mx.spammer.net
| MAIL FROM:<>
V RCPT TO:<greg(_at_)wooledge(_dot_)org>
wooledge.org
However, let's throw a slightly modified SRS into the picture:
wooledge.org
| MAIL
FROM:<greg-SRS0+HHH+TT+wooledge(_dot_)org+greg(_at_)wooledge(_dot_)org>
V RCPT TO:<misspelled(_at_)domain(_dot_)com>
mx.domain.com
What do you gain from this modification of SRS? First, you have
reintroduced the problems of escaping and parsing that the SRS format is
designed to solve. Second, I don't think you gain anything from deciding
the target user before doing the SRS decode.
What this seems to achieve is the ability to do the SRS decode outside the
MTA. However, since this is something that only needs local implementation
on your MTA, you might as well implement it inside the MTA.
Under the normal SRS way of doing things, you would just be the target
host AND the first forwarder, which is fine. Also, you would be able to
skip the SMTP step between the forwarder and yourself on the return path.
Then the following would happen on my end (I run qmail):
0) SPF passes it.
1) qmail-smtpd accepts it, because wooledge.org is in rcpthosts.
2) qmail-send marks it for local delivery, because wooledge.org is in
locals.
3) qmail-local sends it to local user greg, because the local part
begins with "greg-".
This, I think, is where you're relying on the current internals of qmail.
Put libsrs into qmail and at this point, qmail will do a decode because
the local part will begin with SRS0=.
4) ~greg/.qmail-default runs some SRS-aware filter program which
analyzes the local part (environment variable EXT2). If it's not
a legitimate bounce, drop it on the floor; otherwise, deliver it.
My first choice would be the MUA approach, since it requires no patching
of qmail, but other people may choose differently.
Your suggestion works as an idea, but one hopes that with SRS aware MTAs
coming online anyway, it won't be needed.
My first self-criticism would be that the filter must be somewhat clever
in picking out the SRS stuff from the local user part, and delivering
the message appropriately. For example:
RCPT
TO:<greg-slashdot-SRS0+HHH+TT+wooledge(_dot_)org+greg-slashdot(_at_)wooledge(_dot_)org>
should be handled in the same way as <greg-slashdot(_at_)wooledge(_dot_)org>
is
handled, which may be different from <greg(_at_)wooledge(_dot_)org>. This
doesn't
seem to be terribly difficult, so long as nobody uses addresses of the
form foo-srs[0-9]*(_at_)domain(_dot_)
I'll think about this some more and see what I come up with. Comments
are welcome. I'd especially like to know if I'm reinventing a wheel.
I don't think you'll solve it without either markup or escaping, both of
which would break the qmail mechanisms you rely on.
S.
--
Shevek http://www.anarres.org/
I am the Borg. http://www.gothnicity.org/