[moving this to -workers] Lloyd Zusman <[EMAIL PROTECTED]> writes:
> I'm happily using the fairly new "hold" filter action to cause specified > incoming messages to go to my "pending" queue without sending a > confirmation request to the original sender. > > I like having this option, because my confirmation requests are > sometimes interpreted by spammers as a signal that there's a live > recipient at my email address, thereby triggering the sending of more > spam in the future. I know that TMDA will prevent me from seeing this > future spam, but I want some of my addresses to appear totally dead to > all but the selected few from whom I want to accept mail. > > That's why I like "hold". > > However, there are three possible things I'd like to do with a message > that has been sent to the pending queue by means of "hold", and only two > of these seem to be possible: > > 1. I can tell that I don't want any more email from the source of > the message, so I immediately blacklist and delete it via the > interactive version of the tmda-pending program. > > 2. I can tell that I do indeed want to continue to receive email > from this source, in which case I can immediately whitelist > and release it via tmda-pending. > > 3. I'm not sure about this particular sender, and so I want a > confirmation request to be sent, whose response, if received, will > cause tmda to whitelist this person, in its normal fashion. > > The vast majority of the time, incoming messages fall into categories 1 > and 2, and I can already easily handle these cases with the current > version of tmda. However, I'd also like to be able to do number 3. I'm not following the logic here. By looking at the message you should be able to tell whether it is or isn't spam. Why would you need to trigger a confirmation request at that point? > If number 3 is not currently possible, what are the chances of yet > another option being added to the interactive version of > tmda-pending, so that I can choose to cause a confirmation request > to be sent to the original source of the message? I don't think will be very easy, because once the message is written to disk, the important environment variables such as EXTENSION, RECIPIENT and SENDER are lost. TMDA doesn't current store these anywhere. Because so much of the confirmation request code is in tmda-rfilter instead of a shared module (where it probably should be), quite a bit of internal reorganization would also have to be done. _________________________________________________ tmda-workers mailing list ([EMAIL PROTECTED]) http://tmda.net/lists/listinfo/tmda-workers
