Jim Ramsay <[EMAIL PROTECTED]> writes:
When you click the "Whitelist" button in tmda-cgi, it simply calls MsgObj.whitelist() (The whitelist method from class Message in TMDA/Pending.py) Whereas releasing a message by confirmation email does a completely different thing in tmda-rfilter. Also, releasing it by URL confirmation would probably work fine, as this approximates the same code in tmda-rfilter. This same problem would have come up sooner if anyone still used the good old 'tmda-pending' program or PENDING_RELEASE_APPEND.
So, what could the issue in TMDA/Pending.py be? It looks like the "initMessage" routine in the Message class completely ignores x-primary-address.
For a fix, I propose:
OK Jim, you were right afterall; ignore my last two messages in this thread. Tim and I figured this out after an hour or so of bantering tonight on AIM.
What threw me the curve-ball was that I didn't realize that a tmda-cgi "whitelist" also triggers a "release" -- this isn't the same behavior as in tmda-pending. So, I assumed Jeff meant he was seeing the wrong address appended when he confirmed a message, when he was really just whitelisting the message. Grr...
Yeah, maybe the terminology is a bit different in tmda-cgi land. I've always thought it's silly to whitelist an email address but not release it from the queue. When I whitelist a message in tmda-cgi, it's usually an automated website email confirmation I know I'll be hearing from again, so I'd just end up releasing it anyway if they were separate steps.
But maybe we should make a note of that somewhere in the tmda-cgi docs, that "whitelist" also releases, just as "blacklist" also deletes. I suppose I could also add a function for "Whitelist but do not release", but I don't know who would use it.
Anyway, your fix has the right spirit, but I'm going to work on a slightly different implementation this weekend. What I need to do is change all the appends to PENDING_*_APPEND files in Pending.py to honor X-Primary-Address instead of just always using the Return-Path address. This should fix Jeff's problem, and it also the correct behavior I think.
I thought my fix would do that, as Message.whitelist, Message.blacklist, and Message.release all call Message.initMessage to set self.return_path and then append this self.return_path to the appropriate PENDING_*_APPEND list. Changing the code which sets self.return_path should fix all three of these. Then in Message.release I found you want to add the proper return_path (considering x-primary-address) to PENDING_RELEASE_APPEND, but you don't want to use this for the envelope sender in the reinjected message, you want to use the actual return_path (without considering x-primary-address) for that - so I added in the self.envelope_sender which is only used in Message.release to reinject the email. But I defer the decision to you, of course. Just for interest sake, is there some reason my patch wouldn't do all this?
Anyhow, I'm glad we've figured out the problem!
-- Jim Ramsay
_________________________________________________ tmda-workers mailing list ([EMAIL PROTECTED]) http://tmda.net/lists/listinfo/tmda-workers
