From some addresses it's impossible to post into a smartlist
Hello I've been running a couple od mailing lists using smartlist for years. I'm using procmail version 3.22-5 (standard Redhat 7.3) + smartlist 3.15. Recently I've ran into a very strange problems which I think that it might be a bug or inconsistency in smartlist. From some email addresses it's impossible to post a message into a mailing list. The message gets bounced to the list maintainer. All I get in log file is: Subject: Folder: formail -R"From X-From_:" -iDate: -iReturn-Receipt-To: -iRe 1440 In the bounced message header there is: X-Diagnostic: Already on the subscriber list X-Diagnostic: 4 xxxxxxx@xxxxxx.cz 32720 xxxxxxx@xxxxxx.cz The email is already on subscribe list of course, but other emails that are there too work fine. This mostly happens with emails containing . character in a name of a person. But not all of them, some work fine. Seems like some combination of mail header problems. Any suggestions or ideas what to do, or where the problem might be? Thanks in advance for help. Vladia
On Fri, Sep 26, 2003 at 11:50:37PM +0200, Vladislav Kasik wrote:
I've been running a couple od mailing lists using smartlist for years. I'm using procmail version 3.22-5 (standard Redhat 7.3) + smartlist 3.15. Recently I've ran into a very strange problems which I think that it might be a bug or inconsistency in smartlist. From some email addresses it's impossible to post a message into a mailing list. The message gets bounced to the list maintainer.
In the bounced message header there is:
X-Diagnostic: Already on the subscriber list X-Diagnostic: 4 xxxxxxx@xxxxxx.cz 32720 xxxxxxx@xxxxxx.cz
The email is already on subscribe list of course, but other emails that are there too work fine. This mostly happens with emails containing . character in a name of a person. But not all of them, some work fine. Seems like some combination of mail header problems.
First of all you have set the divertcheck flag on to redirect administrative messages to the request address. This check in rc.submit is not perfect. If you want to keep the divertcheck flag on you should send us some more information. I. e. an example, to get an idea what has triggered the redirect to rc.request. Your anonymized X-Diagnostic: lines are good for your subscribers but not helpful for us ;) Werner
Werner Reisberger wrote:
First of all you have set the divertcheck flag on to redirect administrative messages to the request address. This check in rc.submit is not perfect. If you want to keep the divertcheck flag on you should send us some more information. I. e. an example, to get an idea what has triggered the redirect to rc.request. Your anonymized X-Diagnostic: lines are good for your subscribers but not helpful for us ;)
I've been playing with it for a while and the problem seems to be more clear. If From: contains only email addres containing . in name, for example From: name.surname@somedomain.com smartlist behaves the strange way I described. But when it is something like From: Name Surname <name.surname@somedomain.com> all is fine. Apparently some minor bug somewhere in some regular expression ;-) Unfortunately I don't have time to find it and fix it myself. Any help would be appreciated. Vladia
On Sun, 28 Sep 2003, Vladislav Kasik wrote:
I've been playing with it for a while and the problem seems to be more clear. If From: contains only email addres containing . in name, for example From: name.surname@somedomain.com smartlist behaves the strange way I described. But when it is something like From: Name Surname <name.surname@somedomain.com> all is fine. Apparently some minor bug somewhere in some regular expression ;-) Unfortunately I don't have time to find it and fix it myself. Any help would be appreciated.
Most likely it's not in a regular expression, but rather in the address recognition/extraction heuristics you'll find in the "multigram" program which is compiled as part of the procmail suite along with formail and procmail itself.
On Sun, Sep 28, 2003 at 12:46:20PM +0200, Vladislav Kasik wrote:
is fine. Apparently some minor bug somewhere in some regular expression ;-) Unfortunately I don't have time to find it and fix it myself. Any help would be appreciated.
Once again, you give not enough information to find the possible bug. I also have not enough time to search for bugs where I have to guess what's the reason. Werner
participants (3)
-
Bart Schaefer -
Vladislav Kasik -
Werner Reisberger