Treatment of Delivered-To headers (Re: mlmmj-recieve silently

Treatment of Delivered-To headers (Re: mlmmj-recieve silently

[Charlie Brady]

On Fri, 20 Jan 2006, Morten K. Poulsen wrote:

> (now also sent to the list)
>
> Quoting Thomas Goirand <thomas@goirand.fr>:
>> Delivered-To: xen010503-gplhost-com-test-subscribe@xen010503.gplhost.com
> [snip]
>> Would it be possible that mlmmj discrads the message because of the 
>> Delivered-To:?
>
> Yes.
>
> Most likely because of this (mlmmj-process.c):
>
> 519         if(whichto && whichto->emaillist && whichto->emaillist[0]){
> 520                 recipextra = strstr(whichto->emaillist[0], 
> listdelim);
> 521                 if (recipextra)
> 522                         recipextra += strlen(listdelim);
> 523         } else
> 524                 recipextra = NULL;
> 525         myfree(listdelim);

And this:

...
         if(readhdrs[4].token) { /* Delivered-To: (envelope to) */
                 for(i = 0; i < readhdrs[4].valuecount; i++) {
                         find_email_adr(readhdrs[4].values[i], &dtoemails);
                 }
         }
...

The error here is that the Delivered-To header may not match the "envelope 
to", and in the case of virtual domains, it definitely won't. But there is 
no need to guess, just check $RECIPIENT in the environment.

Unless you tell me I'm way off track, I'll try to get a patch together. It 
should be safe to assume that $RECIPIENT won't be set under other MTAs. If 
you think it's not, then we could use a command line flag to only activate 
the environment check under qmail.

Re: Treatment of Delivered-To headers (Re: mlmmj-recieve silently discarding messagesail?)

[Mads Martin Joergensen]

* Charlie Brady <charlieb@budge.apana.org.au> [Jan 21. 2006 04:10]:
> >Quoting Thomas Goirand <thomas@goirand.fr>:
> >>Delivered-To: xen010503-gplhost-com-test-subscribe@xen010503.gplhost.com
> >[snip]
> >>Would it be possible that mlmmj discrads the message because of the 
> >>Delivered-To:?
> >
> >Yes.
> >
> >Most likely because of this (mlmmj-process.c):
> >
> >519         if(whichto && whichto->emaillist && whichto->emaillist[0]){
> >520                 recipextra = strstr(whichto->emaillist[0], 
> >listdelim);
> >521                 if (recipextra)
> >522                         recipextra += strlen(listdelim);
> >523         } else
> >524                 recipextra = NULL;
> >525         myfree(listdelim);
> 
> And this:
> 
> ...
>         if(readhdrs[4].token) { /* Delivered-To: (envelope to) */
>                 for(i = 0; i < readhdrs[4].valuecount; i++) {
>                         find_email_adr(readhdrs[4].values[i], &dtoemails);
>                 }
>         }
> ...
> 
> The error here is that the Delivered-To header may not match the "envelope 
> to", and in the case of virtual domains, it definitely won't. But there is 
> no need to guess, just check $RECIPIENT in the environment.
> 
> Unless you tell me I'm way off track, I'll try to get a patch together. It 
> should be safe to assume that $RECIPIENT won't be set under other MTAs. If 
> you think it's not, then we could use a command line flag to only activate 
> the environment check under qmail.

I would love a patch doing this, with a a commandline option to
configure it. No need to read environment variables anywhere else than
qmail AFAIK.

But I've to admit, that when I wrote this, I deliberately always had in
mind that I ever would need to support qmail. My rationale was that if
one's using qmail, one would just use ezmlm anyway...

-- 
Mads Martin Joergensen, http://mmj.dk
"Why make things difficult, when it is possible to make them cryptic
 and totally illogical, with just a little bit more effort?"
                                 -- A. P. J.

Re: Treatment of Delivered-To headers (Re: mlmmj-recieve silently

[Morten K. Poulsen]

Quoting Mads Martin Joergensen <mmj@mmj.dk>:
>> Unless you tell me I'm way off track, I'll try to get a patch together. It
>> should be safe to assume that $RECIPIENT won't be set under other MTAs. If
>> you think it's not, then we could use a command line flag to only activate
>> the environment check under qmail.
>
> I would love a patch doing this, with a a commandline option to
> configure it. No need to read environment variables anywhere else than
> qmail AFAIK.

Do we need a commandline switch? If qmail puts the values (which other 
MTAs put in headers) in environment variables, the code could be 
changed to something like the following pseudo code:

envelope_to = getenv("RECIPIENT");

if (!envelope_to)
    envelope_to = getheader("Delivered-To");

if (!envelope_to)
    envelope_to = getheader("To");

if (!envelope_to)
    abort();

... and likewise for sender.

Having an extra commandline switch just makes it a tiny bit more 
difficult to set up.

Morten

Re: Treatment of Delivered-To headers (Re: mlmmj-recieve silently discarding messagesail?)

[Mads Martin Joergensen]

* Morten K. Poulsen <morten@afdelingp.dk> [Jan 21. 2006 12:55]:
> Quoting Mads Martin Joergensen <mmj@mmj.dk>:
> >>Unless you tell me I'm way off track, I'll try to get a patch together. It
> >>should be safe to assume that $RECIPIENT won't be set under other MTAs. If
> >>you think it's not, then we could use a command line flag to only activate
> >>the environment check under qmail.
> >
> >I would love a patch doing this, with a a commandline option to
> >configure it. No need to read environment variables anywhere else than
> >qmail AFAIK.
> 
> Do we need a commandline switch? If qmail puts the values (which other 
> MTAs put in headers) in environment variables, the code could be 
> changed to something like the following pseudo code:
> 
> envelope_to = getenv("RECIPIENT");
> 
> if (!envelope_to)
>    envelope_to = getheader("Delivered-To");
> 
> if (!envelope_to)
>    envelope_to = getheader("To");
> 
> if (!envelope_to)
>    abort();
> 
> ... and likewise for sender.
> 
> Having an extra commandline switch just makes it a tiny bit more 
> difficult to set up.

Agreed it's a bit more difficult. I'm just pr. default cautious about
reading environment variables :-)

-- 
Mads Martin Joergensen, http://mmj.dk
"Why make things difficult, when it is possible to make them cryptic
 and totally illogical, with just a little bit more effort?"
                                 -- A. P. J.

Re: Treatment of Delivered-To headers (Re: mlmmj-recieve silently

[Morten K. Poulsen]

Quoting Mads Martin Joergensen <mmj@mmj.dk>:
>> Having an extra commandline switch just makes it a tiny bit more
>> difficult to set up.
>
> Agreed it's a bit more difficult. I'm just pr. default cautious about
> reading environment variables :-)

Fair enough :-)

I've been searching a bit, and it appears that Postfix and Exim also 
sets the environment variables, although EXTENSION must be configured 
for Exim.

http://tmda.net/config-pre.html

Morten

Re: Treatment of Delivered-To headers (Re: mlmmj-recieve silently discarding messagesail?)

[Mads Martin Joergensen]

* Morten K. Poulsen <morten@afdelingp.dk> [Jan 21. 2006 13:06]:
> Quoting Mads Martin Joergensen <mmj@mmj.dk>:
> >>Having an extra commandline switch just makes it a tiny bit more
> >>difficult to set up.
> >
> >Agreed it's a bit more difficult. I'm just pr. default cautious about
> >reading environment variables :-)
> 
> Fair enough :-)
> 
> I've been searching a bit, and it appears that Postfix and Exim also 
> sets the environment variables, although EXTENSION must be configured 
> for Exim.

If these are set, would it perhaps be possible to invoke it like this
from /etc/aliases or .qmail-foo?

 mlmmj-recieve -L /path/to/list -R $RECIPIENT

-- 
Mads Martin Joergensen, http://mmj.dk
"Why make things difficult, when it is possible to make them cryptic
 and totally illogical, with just a little bit more effort?"
                                 -- A. P. J.

Re: Treatment of Delivered-To headers (Re: mlmmj-recieve silently

[Charlie Brady]

On Sat, 21 Jan 2006, Morten K. Poulsen wrote:

> Do we need a commandline switch? If qmail puts the values (which other MTAs 
> put in headers) in environment variables, the code could be changed to 
> something like the following pseudo code:
>
> envelope_to = getenv("RECIPIENT");
>
> if (!envelope_to)
> envelope_to = getheader("Delivered-To");
>
> if (!envelope_to)
> envelope_to = getheader("To");
>
> if (!envelope_to)
> abort();
>
> ... and likewise for sender.

That looks a fine suggestion to me. Clean and simple.

Re: Treatment of Delivered-To headers (Re: mlmmj-recieve silently

[Charlie Brady]

On Sat, 21 Jan 2006, Mads Martin Joergensen wrote:

> Agreed it's a bit more difficult. I'm just pr. default cautious about
> reading environment variables :-)

Perhaps because many system designs are incautious about adding 
environment variables. SysV init is one such system. As soon as an admin 
does "/etc/rc.d/init.d/some_daemon restart" the new daemon is likely to 
have a different environment to the old.

See daemontools or runit for an alternative system for running daemons 
with consistent reliable environment variable setup.