On 13 Feb 2004 at 22:39, 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
Egads, I just notices something about SRS that going to hurt all
Mercury mail users.
Mercury can use the "+" between the user name and a optional tag, i.e.,
"user+tag(_at_)domain(_dot_)com" so the user can track names used in mailing
list
etc. Since their are thousands of Mercury installations out there I
STRONGLY suggest that a different seperator be used and that the SRS
string come after the user name not before it. That way you always see
the user name and can parse everything after it as special information.
I guess that if the SRS part always starts with SRS the "+" could still
be used but you have to account for the user tag, i.e.,
"user+tag+SRS0(_dot_)(_dot_)(_dot_)(_dot_)(_at_)domain(_dot_)com".
I could be totally wrong here so I have to go back and read the SRS
spec again just to make sure plus pass this on to the author of Mercury
as only he know for sure what the problems would be.
mx.domain.com accepts it, but doesn't have a local user by that name,
so it sends back a bounce:
mx.domain.com
| MAIL FROM:<>
V RCPT TO:<greg-SRS0+HHH+TT+wooledge(_dot_)org+greg(_at_)wooledge(_dot_)org>
wooledge.org
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-".
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.
All that's missing is the filter program, and it doesn't even have to
be integrated into an MTA! Hell, I don't even need to su to root!
Oh, and of course I'd need something to rewrite my envelope sender
address on a per-outgoing-message basis. That could be done in one
of the following ways:
0) on the way out the door by qmail-remote (requiring a patch); or
1) at qmail-queue injection time (using a filter invoked by the existing
and widely deployed QMAILQUEUE patch); or
2) by qmail-inject (requiring a patch) as an alternative VERP;[*] or
3) by a send-hook from my MUA (mutt), using the QMAILSUSER environment
variable.
My first choice would be the MUA approach, since it requires no patching
of qmail, but other people may choose differently.
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 looked at VERP, but it doesn't offer any protection against forged
bounces, so far as I can see, unless one keeps a database of
legitimate VERPs for a few weeks or a month. SRS doesn't require
any storage; just some computation. I have gobs and gobs of CPU
to spare for this, since my little vanity domain has 2 users in it
and handles under a thousand messages a day.
--
Greg Wooledge | "Truth belongs to everybody."
greg(_at_)wooledge(_dot_)org | - The Red Hot Chili Peppers
http://wooledge.org/~greg/ |
-------
Sender Policy Framework: http://spf.pobox.com/
Archives at http://archives.listbox.com/spf-discuss/current/
Latest draft at http://spf.pobox.com/spf-draft-20040209.txt
Wiki: http://spfwiki.infinitepenguins.net/pmwiki.php/SenderPermittedFrom/
To unsubscribe, change your address, or temporarily deactivate your
subscription,
please go to
http://v2.listbox.com/member/?listname(_at_)©#«Mo\¯HÝÜîU;±¤Ö¤Íµø?¡
----------------------------------------------------------------------
John Warren
+--------------------------------------------------------------------+
| Any and all use of my email address for bulk email without my |
| expressed permission is prohibited. This means NO JUNK EMAIL, SPAM.|
| Support the anti-Spam amendment, Join at http://www.cauce.org/ |
+--------------------------------------------------------------------+