""Jesse Norell"" <[EMAIL PROTECTED]> said: >> >> > > You might run "grep -ir deliver-to" through the source >> >> > > (1.2, 2.0 and 2.1) and fix all those typo's. I just checked >> >> > > dbmail_2_0_branch, and those are still in there. >> > >> > A possible use of a "deliver-to" header came up on irc the other >> > day - someone wanted to use a program to call dbmail-smtp to deliver >> > a message to a user by adding that header in, >> > eg. "Deliver-To: [EMAIL PROTECTED]". [snip] >> Ok, now it says "delivered-to" which doesn't ring a bell at all. So this >> must have been changed along with the patch. But yes, you're exactly >> right, there was a good intention behind "Deliver-To:" > > So recommending this change is my fault - sorry. A more correct fix > would be to have the auto_notify and auto_reply handling functions actually > look for the correct [headerfield] header, instead of a hard-coded value. > Maybe even putting that in as a config file item would be nice, since it's > usually going to be a system-wide setting. And maybe also look for > Delivered-To if not specified with -t and not found in 'Deliver-To', as it > is the defacto-standard (and probably a better default than Deliver-To, > for auto replies).
Indeed, I think we should get this done before the 2.0.1 on Monday. There's nothing worse than quietly breaking functionality that someone out there is depending on. Adding config file entries with sane defaults in the program should be fine along a stable branch. So the current default, Deliver-To, should stay the way it is. Everywhere that it is hardcoded should be changed to reference a config entry, but with Deliver-To as its default, to keep current behavior. Are there any places that really *shouldn't* be Deliver-To right now? Honest mistakes? Auto_reply seems like a reasonable one, but I'm not sure that I understand what exactly the current behavior maps out as, let alone what the proposed change does. Aaron --
