"Jason R. Mastaler" <[EMAIL PROTECTED]> writes: > Tim Legant <[EMAIL PROTECTED]> writes: > > > I wasn't thinking of throwing an exception. I would just write a > > log message, accept the override and do what it says. > > Where's the impetus to change then? Wouldn't it be easier for users to > just reorganize their filters? As I said, I'd guess that very few even > know about this feature, let alone are using it.
I agree with you on the likelihood of actual use. I was thinking a transition could be helpful, but your "alpha" point below is good. This sort of transition is something that we might do when making a big change to a release after 1.0. > This assumes users are upgrading at every release, which I know they > aren't. Heck, even you and Gre7g are still using a 4 month old TMDA > release <wink>! Yeah, upgrading hasn't been a big priority -- many of the recent changes aren't things I particularly need. I do have an up-to-date development tree, though! > > Once the feature is removed, we'd still have to split the fields in > > text files, so that we don't compare addresses to the whole line, in > > case people don't clean up their files. In that case, maybe an > > exception would be a good idea. > > I think the parser throwing an exception would be appropriate. I think so, too. > > As a wider question, I wonder if there aren't cases where, instead of > > or in addition to logging and deferring, we should send mail to alert > > the user. > > How would a suitable address be determined? A config variable? > What happens if that mail fails/bounces? That's why I included "in addition" in the original suggestion. > I'd also find this extremely annoying if I were the user. Do you find it annoying when cron sends you an error mail? That's a serious question, btw, I'm not being a smart aleck. My suggestion was for rare cases that the user wouldn't typically notice, not for every or even most cases. I'd hate it if every error generated mail, for sure. I was thinking of a certain class of errors that would be rather rare. In fact, their rarity is exactly the reason a user might not notice. > > Throw caution to the wind, eh? > > How so? The parser will throw an exception, deferring the message, > causing the user to fix his configuration. Unless he doesn't notice, because 99% of his mail is still coming in just fine. > No mail is lost. Until 7 days are up (in qmail's case), when the mail is removed from the queue and a bounce is generated, which may or may not cause the original sender to resend. tmda-pending isn't of any help, because the message never gets there. > This of course assumes the user has ignored UPGRADE, it might be > much easier. Yeah, if they read UPGRADE, things usually go smoothly, but that's if they read UPGRADE. :( > Anyway, the parser is your baby, so if you feel strongly about this, > you might poll -users to see how many will actually be affected by > this change. I'd bet dollars to donuts it isn't many, but stranger > things have happened. I don't feel that strongly. I just don't think it's that bad of an idea in certain cases. Tim _________________________________________________ tmda-workers mailing list ([EMAIL PROTECTED]) http://tmda.net/lists/listinfo/tmda-workers
