courier-users — General discussion

Re: [courier-users] courier-mlm list address as user unknown

[Milan O. <cou...@di...>]

On Sat, 2 May 2026 19:14:37 +0000 (UTC)
anfibiosdeasturias-2--- via courier-users
<cou...@li...> wrote:

> Hello
> 
> My problem: courier-mlm list address as user unknown
> 
> courierlm as daemon is running
>  [ + ]  courier-imap
>  [ + ]  courier-imap-ssl
>  [ + ]  courier-mlm
>  [ + ]  courier-mta
>  [ + ]  courier-mta-ssl
> 
> The users listed in /etc/courier/userdb send and receive emails.

OK.

> The list folder seem created and populated fine and with correct
> owner: couriermlm create $mydir/mylist@mydomain
> ADDRESS=mylist@mydomain

This should be OK.

> I haven't spent any time customizing the files nor I done anything
> about "Configuring SMTP pre-filtering of mailing list messages".

This is not necessary per se to get a working mailing list. It could
help to do some filtering and keep list in good shape.

> I think I have created the dot-files correctly. But I have doubts, so
> I have tried different locations for the dot-files. I explain this
> point in more detail below.

You did not get it right in a whole, details are OK.

> It works to subscribe a user via command:
> couriermlm sub $mydir/mylist@mydomain externalmail@externaldomain
> I see externalmail@externaldomain in the binary file:
> cat $mydir/mylist@mydomain/sublist/misc

So mailing list directory is setup right, maintaining it works as
intended, most probably.

> But when I send an email from the subscribed external email to my
> mailing list, the following error appears in /var/log/mail myhostname
> courieresmtpd: started,ip=[myip],port=[52269] myhostname
> courieresmtpd:
> error,relay=myip,port=52269,from=<externalmail@externaldomain>,to=<mylist@mydomain>:
> 550 User <mylist@mydomain> unknown myhostname courieresmtpd:
> error,relay=myip,port=52269,msg="502 ESMTP command error",cmd: DATA

This means you have not the correct 'link' from mail address to maling
list. See below.

> When, prior to the subscription via command, I tried to subscribe via
> email with mylist-subscribe@mydomain from
> externalmail@externaldomain, the same "unknown user" error occurred.

The same as previous point.

> As I said previously, I have doubts with the part about dot-files
> in https://www.courier-mta.org/couriermlm.html
> 
> "For example, if your system account is john, and your mail domain is
> example.com, then the dot-courier(5) file for the mailing list
> <joh...@ex...> is $HOME/.courier-list."
> 
> For example, if I want mylist1@mydomain and mylist2@mydomain, if
> /etc/courier/userdb has user1 and user2 with $HOME1 and $HOME2, I
> think I have to select for example user1 to hosts the lists and I
> have... to create $HOME1/.courier-mylist1 and fill it with the text
> "| couriermlm msg $mydir/mylist1@mydomain" to create
> $HOME1/.courier-mylist2 and fill it with the text "| couriermlm msg
> $mydir/mylist2@mydomain" to create $HOME1/.courier-mylist1-owner and
> fill it with the text "user1@mydomain" to create
> $HOME1/.courier-mylist2-owner and fill it with the text
> "user1@mydomain" to create $HOME1/.courier-mylist1-default and fill
> it with the text "| couriermlm ctlmsg $mydir/mylist1@mydomain" to
> create $HOME1/.courier-mylist2-default and fill it with the text "|
> couriermlm ctlmsg $mydir/mylist2@mydomain"

Which address in your userdb database points to $HOME1? I think this is
the missing point.

> I want to create several mailing lists for my domain (in
> Mailman/Sympa sense), not associated with a human server user. I
> think courier-mlm requires associating them with a user who hosts
> each list in their $HOME. I think that using courier-mlm the lists
> must be associated with a human user listed in /etc/courier/userdb
> and UID>=1000, it cannot be the system user 'courier' (not listed in
> /etc/courier/userdb and UID<1000). I'm assuming the list can have a
> mylist@mydomain address and does not require a user-mylist@mydomain
> address, but then I don't understand how the incoming mail send to
> mylist@mydomain ends in the correct $HOME/dot-file among all the
> users listed in /etc/courier/userdb if system user 'courier' is not
> posible as generic user... if user-mylist@mydomain address is
> required, it could explain the "unknown user" problem, but then
> courier-mlm doesn't work for generic mylist@mydomain lists but only
> personal lists with the username as a prefix to list name, in this
> case courier-mlm would not be a option for generic lists in
> Mailman/Sympa sense.

I have this working easily using default user for a domain (catch all
account). This is achieved by creating a record for alias@domain
address. For this address, property home should be set to $HOME
directory and in this directory you need to create .courier-list,
.courier-list-owner and .courier-list-default files with one line
content per file, exactly as you wrote above.

If you need more details, just ask, but it could help to show some
details from your config - I did some guesswork, which, naturally,
could not be accurate.

Regards,
Milan

[courier-users] courier-mlm list address as user unknown

[<anf...@ya...>]

Hello

My problem: courier-mlm list address as user unknown

courierlm as daemon is running
 [ + ]  courier-imap
 [ + ]  courier-imap-ssl
 [ + ]  courier-mlm
 [ + ]  courier-mta
 [ + ]  courier-mta-ssl

The users listed in /etc/courier/userdb send and receive emails.

The list folder seem created and populated fine and with correct owner:
couriermlm create $mydir/mylist@mydomain ADDRESS=mylist@mydomain

I haven't spent any time customizing the files nor I done anything about "Configuring SMTP pre-filtering of mailing list messages".

I think I have created the dot-files correctly. But I have doubts, so I have tried different locations for the dot-files. I explain this point in more detail below.

It works to subscribe a user via command:
couriermlm sub $mydir/mylist@mydomain externalmail@externaldomain
I see externalmail@externaldomain in the binary file:
cat $mydir/mylist@mydomain/sublist/misc

But when I send an email from the subscribed external email to my mailing list, the following error appears in /var/log/mail
myhostname courieresmtpd: started,ip=[myip],port=[52269]
myhostname courieresmtpd: error,relay=myip,port=52269,from=<externalmail@externaldomain>,to=<mylist@mydomain>: 550 User <mylist@mydomain> unknown
myhostname courieresmtpd: error,relay=myip,port=52269,msg="502 ESMTP command error",cmd: DATA

When, prior to the subscription via command, I tried to subscribe via email with mylist-subscribe@mydomain from externalmail@externaldomain, the same "unknown user" error occurred.

As I said previously, I have doubts with the part about dot-files in https://www.courier-mta.org/couriermlm.html

"For example, if your system account is john, and your mail domain is example.com, then the dot-courier(5) file for the mailing list <joh...@ex...> is $HOME/.courier-list."

For example, if I want mylist1@mydomain and mylist2@mydomain, if /etc/courier/userdb has user1 and user2 with $HOME1 and $HOME2, I think I have to select for example user1 to hosts the lists and I have... 
to create $HOME1/.courier-mylist1 and fill it with the text "| couriermlm msg $mydir/mylist1@mydomain"
to create $HOME1/.courier-mylist2 and fill it with the text "| couriermlm msg $mydir/mylist2@mydomain"
to create $HOME1/.courier-mylist1-owner and fill it with the text "user1@mydomain"
to create $HOME1/.courier-mylist2-owner and fill it with the text "user1@mydomain"
to create $HOME1/.courier-mylist1-default and fill it with the text "| couriermlm ctlmsg $mydir/mylist1@mydomain"
to create $HOME1/.courier-mylist2-default and fill it with the text "| couriermlm ctlmsg $mydir/mylist2@mydomain"

I want to create several mailing lists for my domain (in Mailman/Sympa sense), not associated with a human server user. I think courier-mlm requires associating them with a user who hosts each list in their $HOME. I think that using courier-mlm the lists must be associated with a human user listed in /etc/courier/userdb and UID>=1000, it cannot be the system user 'courier' (not listed in /etc/courier/userdb and UID<1000). I'm assuming the list can have a mylist@mydomain address and does not require a user-mylist@mydomain address, but then I don't understand how the incoming mail send to mylist@mydomain ends in the correct $HOME/dot-file among all the users listed in /etc/courier/userdb if system user 'courier' is not posible as generic user... if user-mylist@mydomain address is required, it could explain the "unknown user" problem, but then courier-mlm doesn't work for generic mylist@mydomain lists but only personal lists with the username as a prefix to list name, in this case courier-mlm would not be a option for generic lists in Mailman/Sympa sense.

Thank you very much.

Re: [courier-users] Jmap?

[Sam V. <mr...@co...>]

Alessandro Vesely writes:

> On 26/04/2026 23:16, Sam Varshavchik wrote:
>> Alessandro Vesely writes:
>>
>>> Hi all,
>>>
>>> are there any plan, or even remote thoughts, about implementing JMAP for  
>>> Courier-MTA?  It seems it's slowly gaining some traction...
>>
>> This is the first time I'm hearing this name, I don't know anything about it.
>>
>> I did come across the updated revision of IMAP, IMAP4rev2, a few years ago.  
>> It also came out of the blue, for me. It was also a random, chance  
>> encounter. It popped up in my Google search results, and I don't remember  
>> what I was searching for, but there it was. I intentionally kept my mouth  
>> shut, and nobody mentioned it to me directly in the years that followed. So  
>> that pretty much says it all (and after skimming through the specification I  
>> pretty much forecasted this level of enthusiasm).
>
>
> Yeah, I'm more or less as enthusiast as you are, but I didn't skim the spec.
>
> Cyrus apparently implements it.  And I see more and more people asking  
> Thunderbird to implement it.  It seems like sooner or later it's coming.

Well, the only thing that a search for "JMAP" found was RFC 8260, "The JSON  
Meta Application Protocol". This does not sound like an evolutionary step  
for IMAP, but rather something completely different.

>> The JSON Meta Application Protocol (JMAP) is used for synchronising
>> data, such as mail, calendars, or contacts, between a client and a
>> server.  It is optimised for mobile and web environments and aims to
>> provide a consistent interface to different data types.

As The Church Lady once said: "Well, isn't that special?"

Translation: "IMAP is losing mind-share, IMAP4rev2 has not fixed it, so  
let's get rid of this flaming dumpster, and start from scratch". I must  
admit that I cannot find any fault in this reasoning, in theory. But just in  
theory.

>> This specification is for the generic mechanism of data
>> synchronisation.  Further specifications define the data models for
>> different data types that may be synchronised via JMAP.

Translation: well, this standard isn't really a standard of any kind.

I will say one argument in favor of this. I've found, over the years, that  
the quality of an Internet standard is inversely proportional to the number  
of pages it takes to define it it.

RFC 3501 was 108 pages.

RFC 8620 is 90 pages.

At least it's a step in the right direction, but not by much. As a  
benchmark, the venerable RFC 821 was only 68 pages, and RFC 2821 goes to 79  
pages. RFC 1939 puts them all to shame, at just 23 pages. Now that's what I  
call a standard.

Anyway, our fearless overlords have only 18 pages left, to specify  
whatever's left to be specified, for a complete implementation for mail  
transfer. What are the chances that they'll make it under the gun?

Re: [courier-users] Jmap?

[Alessandro V. <ve...@ta...>]

On 26/04/2026 23:16, Sam Varshavchik wrote:
> Alessandro Vesely writes:
>
>> Hi all,
>>
>> are there any plan, or even remote thoughts, about implementing JMAP 
>> for Courier-MTA?  It seems it's slowly gaining some traction...
>
> This is the first time I'm hearing this name, I don't know anything 
> about it.
>
> I did come across the updated revision of IMAP, IMAP4rev2, a few years 
> ago. It also came out of the blue, for me. It was also a random, chance 
> encounter. It popped up in my Google search results, and I don't 
> remember what I was searching for, but there it was. I intentionally 
> kept my mouth shut, and nobody mentioned it to me directly in the years 
> that followed. So that pretty much says it all (and after skimming 
> through the specification I pretty much forecasted this level of 
> enthusiasm).


Yeah, I'm more or less as enthusiast as you are, but I didn't skim the spec.

Cyrus apparently implements it.  And I see more and more people asking 
Thunderbird to implement it.  It seems like sooner or later it's coming.


Best
Ale
-- 

Re: [courier-users] Jmap?

[Sam V. <mr...@co...>]

Alessandro Vesely writes:

> Hi all,
>
> are there any plan, or even remote thoughts, about implementing JMAP for  
> Courier-MTA?  It seems it's slowly gaining some traction...

This is the first time I'm hearing this name, I don't know anything about it.

I did come across the updated revision of IMAP, IMAP4rev2, a few years ago.  
It also came out of the blue, for me. It was also a random, chance  
encounter. It popped up in my Google search results, and I don't remember  
what I was searching for, but there it was. I intentionally kept my mouth  
shut, and nobody mentioned it to me directly in the years that followed. So  
that pretty much says it all (and after skimming through the specification I  
pretty much forecasted this level of enthusiasm).

[courier-users] Jmap?

[Alessandro V. <ve...@ta...>]

Hi all,

are there any plan, or even remote thoughts, about implementing JMAP for 
Courier-MTA?  It seems it's slowly gaining some traction...


Best
Ale
-- 

Re: [courier-users] Cannot understand maildrop...

[Alessandro V. <ve...@ta...>]

On Sat 04/Apr/2026 21:34:45 +0200 Sam Varshavchik wrote:
> Alessandro Vesely writes:
> 
>>
>> I had already done that (see above).   I now tried debugging it by:
>>
>> # cat /tmp/test.eml | EXT=cntb sudo -u courier maildrop -V 7 test.mailfilter 
>> 2>&1 |less
>>
>> However, EXT is being reset.
> 
> sudo is resetting the environment by default. My man pages describe the "-- 
> preserve-env=list" option that passes through selected environment variables.


Oh, thank you.  My bad.  Now in the debugging setup it works fine.  Next live 
attempt after Easter...  Probably I should try to catch the environment when 
the message is being delivered.


Best
Ale
-- 

Re: [courier-users] Cannot understand maildrop...

[Sam V. <mr...@co...>]

Alessandro Vesely writes:

>
> I had already done that (see above).   I now tried debugging it by:
>
> # cat /tmp/test.eml | EXT=cntb sudo -u courier maildrop -V 7 test.mailfilter  
> 2>&1 |less
>
> However, EXT is being reset.

sudo is resetting the environment by default. My man pages describe the "-- 
preserve-env=list" option that passes through selected environment variables.

Re: [courier-users] Cannot understand maildrop...

[Alessandro V. <ve...@ta...>]

On Sat 04/Apr/2026 14:00:00 +0200 Sam Varshavchik wrote:
> Alessandro Vesely writes:
>>>>
>>>> I created an alias, or rather two, one accented and one plain:
>>>>
>>>> contabilità@REDACTED.it: amm...@RE...
>>>> con...@RE...: amm...@RE...
>>>>
>>>> This is the first extension I use for this account, so I added a .courier- 
>>>> default which invokes maildrop, just like the regular .courier.
>>>>
>>>> Then in .maildrop I set:
>>>>
>>>> EXITCODE=0
>>>> import EXT
>>>> ...
>>>>         if ($EXT eq "cntb")
>>>>         {
>>>> ...
>>>>
>>>> Messages arrive with a Delivered-To: amm...@RE..., but 
>>>> on the "if" maildrop logs the following:
>>>>
>>>> ../.mailfilter(12): Evaluating IF condition.
>>>> ../.mailfilter(12): Operation on:  and cntb - string equal, result is 0
>>>> ../.mailfilter(12): IF evaluated, result=0
>>>>
>>>> This log was obtained by running maildrop on the message just sent.  (It 
>>>> arrived, but the instructions in the if block were not executed.)
>>>>
>>>> It looks like $EXT was empty.  How come?  In my mailbox I have tons of ifs 
>>>> like that, which work perfectly.
>>>>
>>>> What am I missing?
>>>
>>> The first thing to look into is exactly what's being delivered.
>>>
>>> You want to find a log entry in syslog that records a delivery to the local 
>>> module, "module-local"
>>>
>>> Apr  2 17:00:30 jack courierd[49676]: 
>>> started,id=00000000005A07D1.0000000069CED8ED.0000C43B,from=<mr...@ja...>,module=local,host=mrsam!mlm!1000!1000!/home/mrsam!!,addr=<mrsam>
>>>
>>> "host" here specifies several values, the 2nd one, "mlm" in this case, would 
>>> go into EXT. This message was sent to "mrsam-mlm". Here's one without an 
>>> extension:
>>>
>>> Apr  2 17:07:17 jack courierd[49676]: 
>>> started,id=00000000005A07D1.0000000069CEDA85.0000C56E,from=<mr...@ja...>,module=local,host=mrsam!!1000!1000!/home/mrsam!!,addr=<mrsam>
>>
>>
>> Yup,  I tried several times:
>>
>> Apr  2 13:23:47 22 north courierd: 
>> started,id=00000000005DC04A.0000000069CE51C3.00005439,from=<pos...@RE...>,module=local,hos...@RE...!cntb!117!117!/export/mail/REDACTED.it/amministrazione!!,addr=<amm...@RE...>
>> Apr  2 13:23:47 22 north courierlocal: 
>> id=00000000005DC04A.0000000069CE51C3.00005439,from=<pos...@RE...>,addr=<amm...@RE...>,size=1873,success: Message delivered.
>> Apr  2 13:29:53 22 north courierd: 
>> started,id=00000000005DC04A.0000000069CE5330.000054D8,from=<pos...@RE...>,module=local,hos...@RE...!cntb!117!117!/export/mail/REDACTED.it/amministrazione!!,addr=<amm...@RE...>
>> Apr  2 13:29:53 22 north courierlocal: 
>> id=00000000005DC04A.0000000069CE5330.000054D8,from=<pos...@RE...>,addr=<amm...@RE...>,size=1806,success: Message delivered.
>> Apr  2 13:44:00 22 north courierd: 
>> started,id=00000000005DC2C4.0000000069CE5680.00005756,from=<ve...@ta...>,module=local,hos...@RE...!cntb!117!117!/export/mail/REDACTED.it/amministrazione!!,addr=<amm...@RE...>
>> Apr  2 13:44:00 22 north courierlocal: 
>> id=00000000005DC2C4.0000000069CE5680.00005756,from=<ve...@ta...>,addr=<amm...@RE...>,size=1792,success: Message delivered.
>> Apr  2 14:03:12 22 north courierd: 
>> started,id=00000000005DC2C4.0000000069CE5AFF.00005A51,from=<ve...@ta...>,module=local,hos...@RE...!cntb!117!117!/export/mail/REDACTED.it/amministrazione!!,addr=<amm...@RE...>
>> Apr  2 14:03:12 22 north courierlocal: 
>> id=00000000005DC2C4.0000000069CE5AFF.00005A51,from=<ve...@ta...>,addr=<amm...@RE...>,size=1840,success: Message delivered.
>>
>> Where does maildrop get the extension from?  Not from something inside the 
>> message, like Delivered-To:, right?
> 
> Environment variables. courierlocal sets EXT, and others, in the environment 
> for whatever program it runs to deliver mail.
> 
> Checking the maildropfilter man page, EXT is not one of the variables that are 
> imported into maildrop variables by default. So, just add
> 
> import EXT
> 
> to your maildrop filter.


I had already done that (see above).   I now tried debugging it by:

# cat /tmp/test.eml | EXT=cntb sudo -u courier maildrop -V 7 test.mailfilter 2>&1 |less

However, EXT is being reset.

Hm...

-- 

Re: [courier-users] Cannot understand maildrop...

[Sam V. <mr...@co...>]

Alessandro Vesely writes:

> On Thu 02/Apr/2026 23:12:48 +0200 Sam Varshavchik wrote:
>> Alessandro Vesely writes:
>>>
>>> I created an alias, or rather two, one accented and one plain:
>>>
>>> contabilità@REDACTED.it: amm...@RE...
>>> con...@RE...: amm...@RE...
>>>
>>> This is the first extension I use for this account, so I added a .courier-  
>>> default which invokes maildrop, just like the regular .courier.
>>>
>>> Then in .maildrop I set:
>>>
>>> EXITCODE=0
>>> import EXT
>>> ...
>>>         if ($EXT eq "cntb")
>>>         {
>>> ...
>>>
>>> Messages arrive with a Delivered-To: amm...@RE..., but  
>>> on the "if" maildrop logs the following:
>>>
>>> ../.mailfilter(12): Evaluating IF condition.
>>> ../.mailfilter(12): Operation on:  and cntb - string equal, result is 0
>>> ../.mailfilter(12): IF evaluated, result=0
>>>
>>> This log was obtained by running maildrop on the message just sent.  (It  
>>> arrived, but the instructions in the if block were not executed.)
>>>
>>> It looks like $EXT was empty.  How come?  In my mailbox I have tons of ifs  
>>> like that, which work perfectly.
>>>
>>> What am I missing?
>>
>> The first thing to look into is exactly what's being delivered.
>>
>> You want to find a log entry in syslog that records a delivery to the local  
>> module, "module-local"
>>
>> Apr  2 17:00:30 jack courierd[49676]:  
>> started,id=00000000005A07D1.0000000069CED8ED.0000C43B,from=<mr...@ja...- 
>> scan.com>,module=local,host=mrsam!mlm!1000!1000!/home/mrsam!!,addr=<mrsam>
>>
>> "host" here specifies several values, the 2nd one, "mlm" in this case, would  
>> go into EXT. This message was sent to "mrsam-mlm". Here's one without an  
>> extension:
>>
>> Apr  2 17:07:17 jack courierd[49676]:  
>> started,id=00000000005A07D1.0000000069CEDA85.0000C56E,from=<mr...@ja...- 
>> scan.com>,module=local,host=mrsam!!1000!1000!/home/mrsam!!,addr=<mrsam>
>
>
> Yup,  I tried several times:
>
> Apr  2 13:23:47 22 north courierd:  
> started,id=00000000005DC04A.0000000069CE51C3.00005439,from=<pos...@RE...>,module=local,hos...@RE...! 
> cntb!117!117!/export/mail/REDACTED.it/ 
> amministrazione!!,addr=<amm...@RE...>
> Apr  2 13:23:47 22 north courierlocal:  
> id=00000000005DC04A.0000000069CE51C3.00005439,from=<pos...@RE...>,addr=<amministrazione- 
> cn...@RE...>,size=1873,success: Message delivered.
> Apr  2 13:29:53 22 north courierd:  
> started,id=00000000005DC04A.0000000069CE5330.000054D8,from=<pos...@RE...>,module=local,hos...@RE...! 
> cntb!117!117!/export/mail/REDACTED.it/ 
> amministrazione!!,addr=<amm...@RE...>
> Apr  2 13:29:53 22 north courierlocal:  
> id=00000000005DC04A.0000000069CE5330.000054D8,from=<pos...@RE...>,addr=<amministrazione- 
> cn...@RE...>,size=1806,success: Message delivered.
> Apr  2 13:44:00 22 north courierd:  
> started,id=00000000005DC2C4.0000000069CE5680.00005756,from=<ve...@ta...>,module=local,hos...@RE...! 
> cntb!117!117!/export/mail/REDACTED.it/ 
> amministrazione!!,addr=<amm...@RE...>
> Apr  2 13:44:00 22 north courierlocal:  
> id=00000000005DC2C4.0000000069CE5680.00005756,from=<ve...@ta...>,addr=<amministrazione- 
> cn...@RE...>,size=1792,success: Message delivered.
> Apr  2 14:03:12 22 north courierd:  
> started,id=00000000005DC2C4.0000000069CE5AFF.00005A51,from=<ve...@ta...>,module=local,hos...@RE...! 
> cntb!117!117!/export/mail/REDACTED.it/ 
> amministrazione!!,addr=<amm...@RE...>
> Apr  2 14:03:12 22 north courierlocal:  
> id=00000000005DC2C4.0000000069CE5AFF.00005A51,from=<ve...@ta...>,addr=<amministrazione- 
> cn...@RE...>,size=1840,success: Message delivered.
>
> Where does maildrop get the extension from?  Not from something inside the  
> message, like Delivered-To:, right?

Environment variables. courierlocal sets EXT, and others, in the environment  
for whatever program it runs to deliver mail.

Checking the maildropfilter man page, EXT is not one of the variables that  
are imported into maildrop variables by default. So, just add

import EXT

to your maildrop filter.

Re: [courier-users] Cannot understand maildrop...

[Alessandro V. <ve...@ta...>]

On Thu 02/Apr/2026 23:12:48 +0200 Sam Varshavchik wrote:
> Alessandro Vesely writes:
>>
>> I created an alias, or rather two, one accented and one plain:
>>
>> contabilità@REDACTED.it: amm...@RE...
>> con...@RE...: amm...@RE...
>>
>> This is the first extension I use for this account, so I added a .courier- 
>> default which invokes maildrop, just like the regular .courier.
>>
>> Then in .maildrop I set:
>>
>> EXITCODE=0
>> import EXT
>> ...
>>         if ($EXT eq "cntb")
>>         {
>> ...
>>
>> Messages arrive with a Delivered-To: amm...@RE..., but on 
>> the "if" maildrop logs the following:
>>
>> ../.mailfilter(12): Evaluating IF condition.
>> ../.mailfilter(12): Operation on:  and cntb - string equal, result is 0
>> ../.mailfilter(12): IF evaluated, result=0
>>
>> This log was obtained by running maildrop on the message just sent.  (It 
>> arrived, but the instructions in the if block were not executed.)
>>
>> It looks like $EXT was empty.  How come?  In my mailbox I have tons of ifs 
>> like that, which work perfectly.
>>
>> What am I missing?
> 
> The first thing to look into is exactly what's being delivered.
> 
> You want to find a log entry in syslog that records a delivery to the local 
> module, "module-local"
> 
> Apr  2 17:00:30 jack courierd[49676]: started,id=00000000005A07D1.0000000069CED8ED.0000C43B,from=<mr...@ja...>,module=local,host=mrsam!mlm!1000!1000!/home/mrsam!!,addr=<mrsam>
> 
> "host" here specifies several values, the 2nd one, "mlm" in this case, would go 
> into EXT. This message was sent to "mrsam-mlm". Here's one without an extension:
> 
> Apr  2 17:07:17 jack courierd[49676]: started,id=00000000005A07D1.0000000069CEDA85.0000C56E,from=<mr...@ja...>,module=local,host=mrsam!!1000!1000!/home/mrsam!!,addr=<mrsam>


Yup,  I tried several times:

Apr  2 13:23:47 22 north courierd: started,id=00000000005DC04A.0000000069CE51C3.00005439,from=<pos...@RE...>,module=local,hos...@RE...!cntb!117!117!/export/mail/REDACTED.it/amministrazione!!,addr=<amm...@RE...>
Apr  2 13:23:47 22 north courierlocal: id=00000000005DC04A.0000000069CE51C3.00005439,from=<pos...@RE...>,addr=<amm...@RE...>,size=1873,success: Message delivered.
Apr  2 13:29:53 22 north courierd: started,id=00000000005DC04A.0000000069CE5330.000054D8,from=<pos...@RE...>,module=local,hos...@RE...!cntb!117!117!/export/mail/REDACTED.it/amministrazione!!,addr=<amm...@RE...>
Apr  2 13:29:53 22 north courierlocal: id=00000000005DC04A.0000000069CE5330.000054D8,from=<pos...@RE...>,addr=<amm...@RE...>,size=1806,success: Message delivered.
Apr  2 13:44:00 22 north courierd: started,id=00000000005DC2C4.0000000069CE5680.00005756,from=<ve...@ta...>,module=local,hos...@RE...!cntb!117!117!/export/mail/REDACTED.it/amministrazione!!,addr=<amm...@RE...>
Apr  2 13:44:00 22 north courierlocal: id=00000000005DC2C4.0000000069CE5680.00005756,from=<ve...@ta...>,addr=<amm...@RE...>,size=1792,success: Message delivered.
Apr  2 14:03:12 22 north courierd: started,id=00000000005DC2C4.0000000069CE5AFF.00005A51,from=<ve...@ta...>,module=local,hos...@RE...!cntb!117!117!/export/mail/REDACTED.it/amministrazione!!,addr=<amm...@RE...>
Apr  2 14:03:12 22 north courierlocal: id=00000000005DC2C4.0000000069CE5AFF.00005A51,from=<ve...@ta...>,addr=<amm...@RE...>,size=1840,success: Message delivered.

Where does maildrop get the extension from?  Not from something inside the message, like Delivered-To:, right?


Best
Ale
-- 

Re: [courier-users] Cannot understand maildrop...

[Sam V. <mr...@co...>]

Alessandro Vesely writes:

> Hi Sam,
>
> I created an alias, or rather two, one accented and one plain:
>
> contabilità@REDACTED.it: amm...@RE...
> con...@RE...: amm...@RE...
>
> This is the first extension I use for this account, so I added a .courier- 
> default which invokes maildrop, just like the regular .courier.
>
> Then in .maildrop I set:
>
> EXITCODE=0
> import EXT
> ...
>         if ($EXT eq "cntb")
>         {
> ...
>
> Messages arrive with a Delivered-To: amm...@RE..., but  
> on the "if" maildrop logs the following:
>
> ../.mailfilter(12): Evaluating IF condition.
> ../.mailfilter(12): Operation on:  and cntb - string equal, result is 0
> ../.mailfilter(12): IF evaluated, result=0
>
> This log was obtained by running maildrop on the message just sent.  (It  
> arrived, but the instructions in the if block were not executed.)
>
> It looks like $EXT was empty.  How come?  In my mailbox I have tons of ifs  
> like that, which work perfectly.
>
> What am I missing?

The first thing to look into is exactly what's being delivered.

You want to find a log entry in syslog that records a delivery to the local  
module, "module-local"

Apr  2 17:00:30 jack courierd[49676]: started,id=00000000005A07D1.0000000069CED8ED.0000C43B,from=<mr...@ja...- 
scan.com>,module=local,host=mrsam!mlm!1000!1000!/home/mrsam!!,addr=<mrsam>

"host" here specifies several values, the 2nd one, "mlm" in this case, would  
go into EXT. This message was sent to "mrsam-mlm". Here's one without an  
extension:

Apr  2 17:07:17 jack courierd[49676]: started,id=00000000005A07D1.0000000069CEDA85.0000C56E,from=<mr...@ja...- 
scan.com>,module=local,host=mrsam!!1000!1000!/home/mrsam!!,addr=<mrsam>

[courier-users] Cannot understand maildrop...

[Alessandro V. <ve...@ta...>]

Hi Sam,

I created an alias, or rather two, one accented and one plain:

contabilità@REDACTED.it: amm...@RE...
con...@RE...: amm...@RE...

This is the first extension I use for this account, so I added a 
.courier-default which invokes maildrop, just like the regular .courier.

Then in .maildrop I set:

EXITCODE=0
import EXT
...
         if ($EXT eq "cntb")
         {
...

Messages arrive with a Delivered-To: amm...@RE..., but on 
the "if" maildrop logs the following:

../.mailfilter(12): Evaluating IF condition.
../.mailfilter(12): Operation on:  and cntb - string equal, result is 0
../.mailfilter(12): IF evaluated, result=0

This log was obtained by running maildrop on the message just sent.  (It 
arrived, but the instructions in the if block were not executed.)

It looks like $EXT was empty.  How come?  In my mailbox I have tons of ifs like 
that, which work perfectly.

What am I missing?


Best
Ale
-- 

Re: [courier-users] 550 Unrouteable address

[Sam V. <mr...@co...>]

Alessandro Vesely writes:

> Hi all,
>
> does anyone have any idea what this bounce means?  I got this:
>
> <ab...@ar...>:
>      mail.arattelekom.com [45.67.155.11]:
>  >>> RCPT TO:<ab...@ar...>
>  <<< 550 Unrouteable address

It means that mail server is broken in some way that nobody really cares  
about. It identifies itself as Exim, and some searching might uncover the  
reason why it gives this error, but who cares? Blacklist that incompetent  
network, and move on.

[courier-users] 550 Unrouteable address

[Alessandro V. <ve...@ta...>]

Hi all,

does anyone have any idea what this bounce means?  I got this:

<ab...@ar...>:
      mail.arattelekom.com [45.67.155.11]:
  >>> RCPT TO:<ab...@ar...>
  <<< 550 Unrouteable address

and so:

Final-Recipient: rfc822; ab...@ar...
Action: failed
Status: 5.0.0
Remote-MTA: dns; mail.arattelekom.com [45.67.155.11]
Diagnostic-Code: smtp; 550 Unrouteable address


Best
Ale
-- 

Re: [courier-users] 1024 Mailfilter lines = 556 Address unavailable

[Sam V. <mr...@co...>]

B writes:

>
> Not-So-Fun Fact: If you create a Maildrop filter with at least 1024 lines,  
> your Courier mail system will begin to intermittently respond with "556  
> Address unavailable", which is a PERMANENT failure. Intermittently permanent.

The reason for the original delivery failure is unlikely to be related to  
solely the size of the filter file. And the 556 error is backscatter  
suppression kicking in. A more detailed writeup of backscatter cna be found  
in INSTALL.

The TLDR is that a mail filter delivery failure is considered to be as a  
problem with the mail filter file, it's broken. Do not generate fake bounces  
from mail filters, causing spam to bounce to forged return addresses.

[courier-users] 1024 Mailfilter lines = 556 Address unavailable

[B <b...@my...>]

Not-So-Fun Fact: If you create a Maildrop filter with at least 1024 
lines, your Courier mail system will begin to intermittently respond 
with "556 Address unavailable", which is a PERMANENT failure. 
Intermittently permanent.

Re: [courier-users] makemime not working like before?

[Sam V. <mr...@co...>]

Alessandro Vesely writes:

>> diff --git a/rfc2045/makemime.C b/rfc2045/makemime.C
>> index 84e23459..4c235d64 100644
>> --- a/rfc2045/makemime.C
>> +++ b/rfc2045/makemime.C
>> @@ -180,7 +180,7 @@ static rfc822::fdstreambuf openfile(std::string_view  
>> filename)
>>              exit(1);
>>          }
>>
>> -        fp=std::move(tfile);
>> +        dup2(tfile.fileno(), fd);
>>      }
>>      else
>>      {
>
>
> Thanks; even if I'm not going to try it now, backward compatibility is  
> always good.

Agreed, and now that I tested it, I see that a few more changes are needed,  
for this to actually work right…

Re: [courier-users] makemime not working like before?

[Alessandro V. <ve...@ta...>]

On Sun 08/Feb/2026 20:01:46 +0100 Sam Varshavchik wrote:
> Alessandro Vesely writes:
> 
>> What am I missing?
> 
> The following seems to work:
> 
> [mrsam@jack rfc2045]$ cat args
>       -j
>                 (
>                         -m
>                                 multipart/mixed
>                         -a
>                                 MIME-Version: 1.0
>                         (
>                                 -c
>                                         text/html; charset=utf-8
>                                 htmlintro.txt
>                         )
>                 )
>                 (
>                         -c
>                                 message/rfc822
>                         -a
>                                 Content-Disposition: inline
>                         forwardedmsg.msg
>                 )
> [mrsam@jack rfc2045]$ cat htmlintro.txt
> <h1>Title</h1>
> [mrsam@jack rfc2045]$ cat forwardedmsg.msg
> Subject: a forwarded message
> 
> text
> [mrsam@jack rfc2045]$ ./makemime @- <args
> MIME-Version: 1.0
> Content-Type: multipart/mixed; boundary="=_000b4e68_000000006988dbca_00000001"
> Content-Transfer-Encoding: 8bit
> 
> [ the rest of the message appears well formed ]
> 
> It's pretty clear that it's the attempt to repurpose the same file descriptor 
> that's at issue here. That's going to be plan B. Looking at the entire version 
> of the old makemime C code I think I see how this broke when this was 
> reimplemented in C++. It broke specifically because it's a pipe, this would 
> still work if stdin is a plain file, however I think this patch will fix this:


Yup, I moved the writing of the last part before opening the MM pipe, to a 
third temporary file.  Then setting the temporary filename instead of 
'&0'."\n-\n" works fine.


> diff --git a/rfc2045/makemime.C b/rfc2045/makemime.C
> index 84e23459..4c235d64 100644
> --- a/rfc2045/makemime.C
> +++ b/rfc2045/makemime.C
> @@ -180,7 +180,7 @@ static rfc822::fdstreambuf openfile(std::string_view filename)
>              exit(1);
>          }
> 
> -        fp=std::move(tfile);
> +        dup2(tfile.fileno(), fd);
>      }
>      else
>      {


Thanks; even if I'm not going to try it now, backward compatibility is always good.


Best
Ale
-- 

Re: [courier-users] makemime not working like before?

[Sam V. <mr...@co...>]

Alessandro Vesely writes:

> Hm... I tried the following instead of the code above, but it prints the  
> help text.
>
> 	open(MM, '|-', 'makemime @-') or warn("can't fork: $!"), $failed = 5;
> 	print MM "-j
> 		(
> 			-m
> 				multipart/mixed
> 			-a
> 				MIME-Version: 1.0
> 			(
> 				-c
> 					text/html; charset=utf-8
> 				". '&'. fileno($fb) ."
> 			)
> 		)
> 		(
> 			-c
> 				message/rfc822
> 			-a
> 				Content-Disposition: inline
> 			". '&0' ."
> 		)
> 		" or warn("bad MM pipe: $!"), $failed = 6;
>
> What am I missing?

The following seems to work:

[mrsam@jack rfc2045]$ cat args
      -j
                (
                        -m
                                multipart/mixed
                        -a
                                MIME-Version: 1.0
                        (
                                -c
                                        text/html; charset=utf-8
                                htmlintro.txt
                        )
                )
                (
                        -c
                                message/rfc822
                        -a
                                Content-Disposition: inline
                        forwardedmsg.msg
                )
[mrsam@jack rfc2045]$ cat htmlintro.txt
<h1>Title</h1>
[mrsam@jack rfc2045]$ cat forwardedmsg.msg
Subject: a forwarded message

text
[mrsam@jack rfc2045]$ ./makemime @- <args
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="=_000b4e68_000000006988dbca_00000001"
Content-Transfer-Encoding: 8bit

[ the rest of the message appears well formed ]

It's pretty clear that it's the attempt to repurpose the same file  
descriptor that's at issue here. That's going to be plan B. Looking at the  
entire version of the old makemime C code I think I see how this broke when  
this was reimplemented in C++. It broke specifically because it's a pipe,  
this would still work if stdin is a plain file, however I think this patch  
will fix this:

diff --git a/rfc2045/makemime.C b/rfc2045/makemime.C
index 84e23459..4c235d64 100644
--- a/rfc2045/makemime.C
+++ b/rfc2045/makemime.C
@@ -180,7 +180,7 @@ static rfc822::fdstreambuf openfile(std::string_view filename)
 			exit(1);
 		}

-		fp=std::move(tfile);
+		dup2(tfile.fileno(), fd);
 	}
 	else
 	{

Re: [courier-users] makemime not working like before?

[Alessandro V. <ve...@ta...>]

On Sun 08/Feb/2026 18:01:49 +0100 Sam Varshavchik wrote:
> Alessandro Vesely writes:
>
>> The script uses makemime like so:
>>
>>     open(MM, '|-', 'makemime @-') or warn("can't fork: $!"), $failed = 5;
>>
>>     print MM "-j
>>         (
>>             -m
>>                 multipart/mixed
>>             -a
>>                 MIME-Version: 1.0
>>             (
>>                 -c
>>                     text/html; charset=utf-8
>>                 ". '&'. fileno($fb) ."
>>             )
>>         )
>>         ".'&0'."\n-\n" or warn("bad MM pipe: $!"), $failed = 6;
>>
>> The script reads an email message with an attachment.  In the code above, 
>> <$fb> is a temporary file where the previous part of the script wrote an HTML 
>> description of the attachment.
>>
>> The original message was saved as another temp file, <$fh>.  Before opening 
>> MM, the header from <$fh> was printed to stdout, except for MIME header 
>> fields which were saved to $mimestuff.  Now, the rest of the original message 
>> is being printed as a second entity, a multipart/mixed:
>
> The second parameter to -j, what seems to be &0 here, also needs to be a MIME 
> file. It's not clear to me from your description that you already fed the 
> attachment to  -c, and are piping that into standard input.


The attachment after the -c, <$fb> is already written and re-positioned with 
seek($fb, 0, SEEK_SET).

Stdin, the &0, is going to be written right away, after \n-\n.  The script will 
first pipe the MIME headers.  In the test file I'm using not, it is just two lines:

MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="=_0000146e_000000006987e9fb_00000001"

then comes the prologue, the first boundary, the first entity, ...

The syntax, the '&0'."\n-\n" bit, looks redundant to me, since &0 and "-" both 
refer to stdin.  However, if I remove either part makemime prints the help text.


> I think that's always been the case, but the difference in behavior might be 
> due to the new MIME parser.


Could it be because stdin provides both the parameters and the contents of the 
last entity?


> If it's a manually assembled MIME file, it should have its own Mime-Version: 
> 1.0 header.


It does.


> You can always replace the second parameter with another set of parenthesized 
> recursive options, and supply a -c there, to MIME-encode a raw file.


Hm... I tried the following instead of the code above, but it prints the help text.

	open(MM, '|-', 'makemime @-') or warn("can't fork: $!"), $failed = 5;
	print MM "-j
		(
			-m
				multipart/mixed
			-a
				MIME-Version: 1.0
			(
				-c
					text/html; charset=utf-8
				". '&'. fileno($fb) ."
			)
		)
		(
			-c
				message/rfc822
			-a
				Content-Disposition: inline
			". '&0' ."
		)
		" or warn("bad MM pipe: $!"), $failed = 6;

What am I missing?

Best
Ale
-- 

Re: [courier-users] makemime not working like before?

[Sam V. <mr...@co...>]

Alessandro Vesely writes:

> The script uses makemime like so:
>
> 	open(MM, '|-', 'makemime @-') or warn("can't fork: $!"), $failed = 5;
>
> 	print MM "-j
> 		(
> 			-m
> 				multipart/mixed
> 			-a
> 				MIME-Version: 1.0
> 			(
> 				-c
> 					text/html; charset=utf-8
> 				". '&'. fileno($fb) ."
> 			)
> 		)
> 		".'&0'."\n-\n" or warn("bad MM pipe: $!"), $failed = 6;
>
> The script reads an email message with an attachment.  In the code above,  
> <$fb> is a temporary file where the previous part of the script wrote an  
> HTML description of the attachment.
>
> The original message was saved as another temp file, <$fh>.  Before opening  
> MM, the header from <$fh> was printed to stdout, except for MIME header  
> fields which were saved to $mimestuff.  Now, the rest of the original  
> message is being printed as a second entity, a multipart/mixed:

The second parameter to -j, what seems to be &0 here, also needs to be a  
MIME file. It's not clear to me from your description that you already fed  
the attachment to  -c, and are piping that into standard input.

I think that's always been the case, but the difference in behavior might be  
due to the new MIME parser.

If it's a manually assembled MIME file, it should have its own Mime-Version:  
1.0 header.

You can always replace the second parameter with another set of  
parenthesized recursive options, and supply a -c there, to MIME-encode a raw  
file.

[courier-users] makemime not working like before?

[Alessandro V. <ve...@ta...>]

Hi,

I have a Perl script which stopped working.  When I run it with an older 
version of makemime it works.  With a newer version, courier-1.5.0, it doesn't.

The script uses makemime like so:

	open(MM, '|-', 'makemime @-') or warn("can't fork: $!"), $failed = 5;

	print MM "-j
		(
			-m
				multipart/mixed
			-a
				MIME-Version: 1.0
			(
				-c
					text/html; charset=utf-8
				". '&'. fileno($fb) ."
			)
		)
		".'&0'."\n-\n" or warn("bad MM pipe: $!"), $failed = 6;

The script reads an email message with an attachment.  In the code above, <$fb> 
is a temporary file where the previous part of the script wrote an HTML 
description of the attachment.

The original message was saved as another temp file, <$fh>.  Before opening MM, 
the header from <$fh> was printed to stdout, except for MIME header fields 
which were saved to $mimestuff.  Now, the rest of the original message is being 
printed as a second entity, a multipart/mixed:

	if ($failed == 0)
	{
		print MM $mimestuff;
		print MM "\n";

		while (<$fh>)
		{
			print MM $_;
		}
	}
	close MM or warn "error closing MM pipe: $!";

No warning gets printed.  The HTML description is printed fine, but the 
attachment is lost.  The message produced terminates with an empty entity, like so:

--=_000035c3_0000000069888f36_00000001

--=_000035c3_0000000069888f36_00000001--

When run using the old makemime, the multipart, from header to closing 
boundary, was copied as a second entity.

Is there an easy fix to make the script work with the new makemime?


In case the above is unclear, the whole script is published here:
https://www.tana.it/sw/dmarc-xsl/


Best
Ale
-- 

Re: [courier-users] Debugging new server authentication

[Sam V. <mr...@co...>]

Soren Stoutner writes:

> Thanks for the followup.  I am the maintainer of the official Debian  
> packages.
> Is there anything you think could be improved about the packaging or the
> Debian-specific documentation shipped within the packaging that would make  
> the
> new setup process easier?

It's not really a packaging or a documentation issue. Robust error reporting  
has been my historical blind spot. What needs to happen is to figure out a  
better way to report the cause of these errors.

Re: [courier-users] Debugging new server authentication

[Soren S. <so...@de...>]

On Monday, February 2, 2026 12:38:25 AM Mountain Standard Time Krystal Clarke 
via courier-users wrote:
> And I've solved the problem...
> 
> 
> I was SURE that I had set the owner of the 'courier' table to be the
> correct PostgreSQL user when I created that table, but it turns out that
> I hadn't...
> 
> Corrected that and 'authtest' succeeds.

Thanks for the followup.  I am the maintainer of the official Debian packages.  
Is there anything you think could be improved about the packaging or the 
Debian-specific documentation shipped within the packaging that would make the 
new setup process easier?

-- 
Soren Stoutner
so...@de...