mlmmj bug with qmail+vpopmail

mlmmj bug with qmail+vpopmail

[Alexander Kardailsky]

Dear mlmmj,

  Just installed the latest version of the mlmmj on freebsd 6.1 box
  and tried to work with it. I created test list sw-test and
  configured .qmail-sw-test and .qmail-sw-test-default files.
  Subscription was ok. However, when I tried to send email to the list
  I got the following error: 
  listcontrol.c:740: Unknown command "test". Ignoring mail: Unknown error: 0
  Anyone else has such problem?
  
-- 
Best regards,
 Alexander                          

Re: mlmmj bug with qmail+vpopmail

[Thomas Goirand]

Alexander Kardailsky wrote:
> Dear mlmmj,
> 
>   Just installed the latest version of the mlmmj on freebsd 6.1 box
>   and tried to work with it. I created test list sw-test and
>   configured .qmail-sw-test and .qmail-sw-test-default files.
>   Subscription was ok. However, when I tried to send email to the list
>   I got the following error: 
>   listcontrol.c:740: Unknown command "test". Ignoring mail: Unknown error: 0
>   Anyone else has such problem?

First of all, you shouldn't use vpopmail, it's simply useless (unless
you like it's stupid multiple flat password file thing), a bare qmail
has virtual users integrated.

Thomas

Re: mlmmj bug with qmail+vpopmail

[Alexander Kardailsky]

Dear Alexander,

Saturday, July 21, 2007, 2:10:17 PM, you wrote:

> Dear mlmmj,

>   Just installed the latest version of the mlmmj on freebsd 6.1 box
>   and tried to work with it. I created test list sw-test and
>   configured .qmail-sw-test and .qmail-sw-test-default files.
>   Subscription was ok. However, when I tried to send email to the list
>   I got the following error: 
>   listcontrol.c:740: Unknown command "test". Ignoring mail: Unknown error: 0
>   Anyone else has such problem?

    I think I fixed that problem. I've added one more check in
    mlmmj-process.c :

-  } else if(dtemails.emailcount >= 1) {
+  } else if(dtemails.emailcount >= 1 && strcmp(dtemails.emaillist[0], getlistaddr(listdir)) != 0) {
    /* parse the (first) Delivered-To: header */
    recipextra = recipient_extra(listdir, dtemails.emaillist[0]);
-  } else if(toemails.emailcount >= 1) {
+  } else if(toemails.emailcount >= 1 && strcmp(toemails.emaillist[0], getlistaddr(listdir)) != 0) {
    /* parse the (first) To: header */
    
   I think there is no needed recipextra in case mailing list
   name and To: or Delivered-To: addresses are equals.


-- 
Best regards,
 Alexander

Re: mlmmj bug with qmail+vpopmail

[Morten K. Poulsen]

Hi Alexander,

Alexander Kardailsky <kardailsky@gmail.com> wrote:
>>   configured .qmail-sw-test and .qmail-sw-test-default files.
[snip]
>     I think I fixed that problem. I've added one more check in
>     mlmmj-process.c :
> 
> -  } else if(dtemails.emailcount >= 1) {
> +  } else if(dtemails.emailcount >= 1 && strcmp(dtemails.emaillist[0],
> getlistaddr(listdir)) != 0) {
[snip]
>    I think there is no needed recipextra in case mailing list
>    name and To: or Delivered-To: addresses are equals.

It is true that the parsing is not needed, but I can not see how
your patch fixes anything.

Your delivery agent should set one of the DEFAULT, EXTENSION
or LOCAL_PART_SUFFIX environment variables. If it does not, mlmmj
parses the headers in an attempt to find the envelope to address
anyway. This is a fall back. Don't rely on it. There is - as far as I can
see - no way it can parse the address if the address itself contains
the delimiter.

test-foo-bar <-- is it test-foo with extension bar or test with extension
foo-bar? Only the mail server can tell.

Without your patch:
test -> test / NULL
test-foo -> test / foo
test-foo-bar -> test / foo-bar

With your patch:
test -> test / NULL
test-foo -> test-foo / NULL
test-foo-bar -> test / foo-bar

See the problem?

You have two options here:
- use a delivery agent which reveals the envelope information
- use an address without the delimiter embedded

Morten

-- 
Morten K. Poulsen <morten@afdelingp.dk>
http://www.afdelingp.dk/

Re: mlmmj bug with qmail+vpopmail

[Morten K. Poulsen]

Hi Alexander,

Alexander Kardailsky <kardailsky@gmail.com> wrote:
>> See the problem?
> 
>   Not sure.
>   test-foo ->> test-foo / NULL
>   This is only if your mailing list have this address
>   test-foo@ If it has different one there would be test / foo

Yes. But all of this is only a problem if you are using the
delimiter *in* the address. Your list is IIRC called test-sw
and you are using a dash as delimiter.

With your patch test-sw@example.org will not be parsed.
However test-sw-faq@example.org will still be parsed.
And it will be parsed into test / sw-faq. Mlmmj will then
reject that mail, because there is no "sw-faq" command.
If you were using + as delimiter it would not be a problem:
test-sw+faq@example.org is unambiguous.

>   It doesn't matter what you have test-'foo-bar' or
>   test-foo-'bar' because there is comparison with mailing
> list address.

The patch fixes the case where there is no extension. But
as far as I can see it will fail with one. Maybe I am wrong,
but please explain how your patch will make mlmmj parse
test-sw-faq@example.org into test-sw / faq.

You could change recipient_extra() to look for the list's
address in the beginning of the given address, but consider
this case: A list has two names (yes, mlmmj supports this)
test@example.org and test-sw@example.org. How do you
parse test-sw-faq@example.org?

Morten

-- 
Morten K. Poulsen <morten@afdelingp.dk>
http://www.afdelingp.dk/