bob-tmda-fwdbounce=<encryptedSend>[EMAIL PROTECTED]
<encryptedSender> is just "tmda-address -s [EMAIL PROTECTED]"
Upon a bounce we can confirm this message by checking if <encryptedSend> and [EMAIL PROTECTED] would match using out CRYPTKEY
This of course allows the receiver to know the address that sent the message in the first place. (which I don't see as a problem)
Good point! I like that idea - but why not implement it like a keyword-tagged address where the tag name is "fwdbounce" and the keyword is "bob#sender.org" (may be easier to implement):
bob-fwdbounce-bob#sender.org-<keywordcookie>@sender.org
Except that either way it still leaves my machine open to forwarding spam, a little. Consider this scenario:
- [EMAIL PROTECTED] sends me [EMAIL PROTECTED] a message, and I have TMDA forward it to [EMAIL PROTECTED]
- TMDA changes the envelope into i.am-fwdbounce-test#domain.com-<cookie>@jimramsay.com and sends it off.
- If it bounces, TMDA takes it, turns it back into [EMAIL PROTECTED] and forwards the bounce there, with a bit-bucket envelope. (so that double bounces will be trashed)
- Two months later, a spammer somehow harvests the i.am-fwdbounce-test#domain.com-<cookie>@jimramsay.com address, and sends a Viagra add there.
- TMDA changes the envelope back into [EMAIL PROTECTED] and spams him via my server. Granted that said spammer cannot change test#domain.com into anything else since TMDA would reject something not matching that sender, and that the likelyhood of a spammer getting this envelope is very low, I'm still *kind of* an open relay forever, and I'd like to avoid that.
Some solutions:
1 - Use a dated keyword cookie so that this forward path is only open for a short time. (14 days should be long enough for most bounces, right?) How could one make a dated keyword cookie? Is it possible?
2 - Use just a dated cookie, since there is small likelyhood that this envelope will ever be harvested anyway. This would be easiest.
3 - Use a cookie which is somehow dependent on the message contents AND the sender so that only a bounce can get through. But I can't think of a robust way to do this, since everybody bounces differently. Forget it.
4 - We need to somehow get the IP address of the machine sending the bounce message, and require that forwards store the email address is DELIVERY (this won't work for addresses in .qmail files). Then when you get an incoming mail tagged with 'fwdbounce', use SPF.py to check the address of the machine producing the bounce against the domain in the DELIVERY variable (you need the DELIVERY variable for bounces with null <> envelopes). This would be the most secure, but I don't know how we'd get the IP address of the connecting machine as late as TMDA gets the message, except by looking up the host in the latest Received-by: header, which may not be completely reliable.
Any other ideas?
-- Jim Ramsay
_________________________________________________ tmda-workers mailing list ([EMAIL PROTECTED]) http://tmda.net/lists/listinfo/tmda-workers
