BRILLIANT! I should have thought of that... I am redfaced... thanks!
Much better than stripping, hacking existing code and more flexible - with no suid and the ability to do custom confirmation methods (could if needed become more than a request to confirm - and that could even be optional by id - I love it! I thought I had a pretty solid mail system before, but some of the things I'm organizing with the inspiration of this tool are pretty darn sweet - very fun! Thanks! m/ > -----Original Message----- > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] > Behalf Of Tim Legant > Sent: Thursday, January 22, 2004 12:27 PM > To: [EMAIL PROTECTED] > Subject: Re: without having read the code... > > > "Mitch (WebCob)" <[EMAIL PROTECTED]> writes: > > > I gotcha there David, I was asking in general if a rewrite would be > > considered onerous. I'd like to use the url confirmation > method, but like > > some other commenters here I'm worried about the performance > hit thousands > > of requests to this wrapped cgi could cause - can rewrite JUST > THIS FUNCTION > > in C or PHP to avoid that, and also to simplify things (I don't want all > > that functionality exposed). > > > > Is that explained better? > > The easiest way to do this without using tmda-cgi at all (it sounds > like you just want to put up a "Click here to confirm" sort of page) > is to set up a handler (PHP, C, whatever) at whatever URL you have > configured CGI_URL as and have that code send an empty email to the > confirmation address. > > The URL in the confirmation request includes the effective user id of > the recipient (the TMDA user) and the cryptographic cookie created > using that recipient's crypt_key. Your code would need to look up the > user using the EUID (from /etc/passwd) and create a To: address based > on that user's name, the keyword "confirm", the cookie and the email > domain of the recipient. The URL is formatted like this: > > http://your.dom/yourpage.(html|php|whatever)?EUID.COOKIE > > For virtual domains the EUID is the same for all virtual users so, in > addition, the URL contains the recipient's address, formatted like > this: > > http://your.dom/yourpage.php?EUID&RCPT_ADDR&COOKIE > > The confirm address is formatted like this (assuming '-' is the > Defaults.RECIPIENT_DELIMITER): > > [EMAIL PROTECTED] > > By default TMDA creates a confirm address using the first element of > the Defaults.TAGS_CONFIRM list. You can actually use any element in > that list. Most people don't change this, so it is "confirm". > > In any case, make sure that your code uses a word that will work for > all of your users. If you don't allow users to edit their config, > this is all under your control. If you do allow them to edit their > config, you may need to issue a warning to users that, regardless of > what additional values they use in the TAGS_CONFIRM list, "confirm" > should always be there if they want the URL confirmation to work. > > You can write whatever PHP is necessary to turn the URL parameters > into an email address and send the confirmation through your mail > system. tmda-filter will receive that message and will release the > original mail and, if the recipient is so configured, append the > sender's address to the CONFIRM_APPEND file, just as if the sender had > sent the confirmation. > > NOTE: The address appended to the CONFIRM_APPEND file is either the > X-Primary-Address or the envelope sender address from the *original > message*. It is not derived from the confirmation, so your code > doesn't have to magically determine who the sender is. > > > Tim > > _____________________________________________ > tmda-users mailing list ([EMAIL PROTECTED]) > http://tmda.net/lists/listinfo/tmda-users > _____________________________________________ tmda-users mailing list ([EMAIL PROTECTED]) http://tmda.net/lists/listinfo/tmda-users
