On Mon, Oct 30, 2006 at 02:47:33PM -0500, Mark Horn wrote: > 1) I'd be able to evaluate emails while the actual originator is > connected to me. In order to communicate results, TMDA relies on the
This is good, as it would prevent TMDA from sending bounces to joe-job addresses. This would go a long way towards resolving that particular issue. As you say, it would only work for rejections, but it's still an awfully good idea. > My first goal would be to implement bounces only. Eventually, I'd > like to figure out if I could issue challenges through this mechanism. I don't know if you can do it through the policy service, but even if you could, I'm not sure SMTP supports what would need to happen. ETRN comes close, but to the best of my understanding doesn't reuse the existing connection. In order to issue challenges in a way that doesn't fall for a joe-job, you'd need to send the challenge back through the connecting SMTP server, which isn't really a supported feature AFAIK. Also, TMDA can't issue a challenge until the email is written into the pending queue--even it could, that seems problematic in that you'd be issuing a challenge to a mail that may yet bounce before reaching a real inbox (e.g. bounces from the MDA). > Thoughts? Objections? Advice? My main concern would be one of security. If the policy daemon runs as root, that could be a sore spot. A Rube Goldberg alternative might be to have an unpriveleged policy daemon send a message to the user with TMDA support for sending special replies back to the daemon. In other words, if TMDA sees a message with an X-TMDA-POLICYDAEMON header, it knows to reply using a named pipe or something. Or maybe I'm just on crack. :) -- Unabashedly littering the information superhighway with detritus like this for over 15 years now. _________________________________________________ tmda-workers mailing list ([email protected]) http://tmda.net/lists/listinfo/tmda-workers
