Re: [vchkpw] The future of valias other topics

2007-01-06 Thread John Simpson
On 2007-01-05, at 1334, Rick Widmer wrote: I think the best thing to do with the localrelay patch is to put it into the contrib directory where people who need it can find it easily. The main reason I think this is because smtp after pop is obsolete. All the email clients I know of

Re: [vchkpw] Rename user's .qmail to .vpopmail

2007-01-06 Thread Rick Widmer
Tom Collins wrote: Who the heck is Charles Cazabon and why should I care that he thinks our files shouldn't be called .qmail? Charles is probably the most knowledgeable person answering questions on the qmail list. He can be a pain to work with sometimes, but if Charles and DJB were

[vchkpw] Local relay patch

2007-01-06 Thread Rick Widmer
John Simpson wrote: i think the idea of an onauth hook, similar to how onchange works, will minimize the amount of code changes needed for vpopmail, while opening the door for somebody (like joshua) to write a relay-after-pop3/imap system as external scripts if he likes, and also opening

Re: [vchkpw] The future of valias other topics

2007-01-06 Thread Tom Collins
On Jan 6, 2007, at 12:26 AM, John Simpson wrote: as for making .vpopmail* files fully compatible with .qmail* files, that could also be a good thing- however the interface (in terms of which environment variables will be passed to scripts run from the .vpopmail file, what values will be

Re: [vchkpw] Rename user's .qmail to .vpopmail

2007-01-06 Thread Tom Collins
On Jan 6, 2007, at 3:34 AM, Rick Widmer wrote: Tom Collins wrote: Now that .qmail files are fully supported in vpalias.c, we can update QmailAdmin to use the vpopmail API to work with the files, and it won't know anything about their contents. I'm planning on it. I may even have it done in

Re: [vchkpw] Local relay patch

2007-01-06 Thread John Simpson
On 2007-01-06, at 0648, Rick Widmer wrote: John Simpson wrote: and it also means that vpopmail itself will never have to worry about relay-after-pop3 issues again- they can be referred to whoever wrote the external scripts that they will be using. I don't agree about this. We already

Re: [vchkpw] Local relay patch

2007-01-06 Thread Joshua Megerman
On Saturday 06 January 2007 12:56, John Simpson wrote: On 2007-01-06, at 0648, Rick Widmer wrote: John Simpson wrote: and it also means that vpopmail itself will never have to worry about relay-after-pop3 issues again- they can be referred to whoever wrote the external scripts

Re: [vchkpw] Local relay patch

2007-01-06 Thread John Simpson
On 2007-01-06, at 1310, Joshua Megerman wrote: On Saturday 06 January 2007 12:56, John Simpson wrote: joshua? if we add an onauth hook, how long would it take you to duplicate what vpopmail already does, using external scripts? i'm thinking maybe a set of files in a subdirectory under contrib,

Re: [vchkpw] Local relay patch

2007-01-06 Thread Rick Widmer
John Simpson wrote: you're right, the onauth code itself is simple- i could probably write it in about fifteen minutes, and i'm sure several other people could as well. yeah, vi vpopmail.c duplicate the existing call_onchange function line range of new functions/change/auth/g line

Re: [vchkpw] Rename user's .qmail to .vpopmail

2007-01-06 Thread Rick Widmer
Tom Collins wrote: On Jan 6, 2007, at 3:34 AM, Rick Widmer wrote: Tom Collins wrote: Now that .qmail files are fully supported in vpalias.c, we can update QmailAdmin to use the vpopmail API to work with the files, and it won't know anything about their contents. I'm planning on it. I

Re: [vchkpw] The future of valias other topics

2007-01-06 Thread Rick Widmer
Tom Collins wrote: i respect charles and his opinion about .qmail and .vpopmail files... but making charles happy is not a primary goal of vpopmail, and it's certainly not an excuse to unsafely force this change on all of the existing vpopmail systems out there. i think it makes more

Re: [vchkpw] The future of valias other topics

2007-01-06 Thread Tom Collins
On Jan 6, 2007, at 5:15 PM, Rick Widmer wrote: Yes there will be a sequence field in the table. The question is how do we add the tools. Do we break the existing alias interface, or do we provide an alternate interface for when order is important, leaving all existing code intact. I'm