On Wed, Aug 18, 2004 at 03:11:34PM -0500, Kyle Hasselbacher wrote: | I sent Allen a test message, and this is what I witnessed. | | 1. My envelope sender was rewritten on the way to TMDA, so TMDA responded to | some ickiness @bounce2.pobox.com | | 2. TMDA responds to the ickiness, and bounce2 rewrites it back to my real | address so the challenge arrives just fine. | | 3. I replied to the confirmation address, and I got a "Confirmation | accepted" back, so I assume that Allen received my test email (confirm, | Allen?).
Yep. | At this point, Allen has probably whitelisted the icky rewritten address, | not my real address. ... Correct. | ... When I send another email, TMDA blocks it and | challenges me again because the new email comes from a new (differently icky) | envelope sender. Yes again. There's some timing involved; if I read the SRS page correctly, the hash in the icky address involves the current time. So it's likely to be different from message to message, but that might not be guaranteed. | For this to all work as it's supposed to, TMDA needs to detect the rewritten | address and treat it differently somehow. Not being much of an SRS-head, | I'm not show how that would work. I suppose someone could put a SRS-decoder | wrapper around tmda-incoming so that it sees the "proper" $SENDER | environment variable, and that would take care of it, but I'm just guessing. With the SRS scheme that pobox uses, you can recover the original envelope sender from the SRS version. But I don't know if that's guaranteed to be possible (an MTA might keep a database rather than copying all the information into the SRS version), or how many different SRS schemes are likely to be in play. Definitely beyond my level of expertise... | As for why your 'to' input filters aren't working, I can't tell what's going | on there. I don't see what SRS has to do with it. I'm not sure either. I've convinced myself that my previous guess about it is incorrect, but I haven't figured out what's really happening. SRS definitely triggered a glitch, but it might be my configuration rather than a TMDA issue. At any rate, it's less important than the confirmation problem, because I have a workaround for it. Thanks, Allen _____________________________________________ tmda-users mailing list ([EMAIL PROTECTED]) http://tmda.net/lists/listinfo/tmda-users
