Re: Sporadically deferred mail, followed by 456 Address temporarily unavailable

On 21.10.2023 21:55, Sam Varshavchik wrote:
> Norbert Harrer writes:
>> 1. There was no sign of the maildrop error in the log files. How can I
>> make maildrop errors show up in /var/log/mail.log? When I run maildrop
>> manually from the command line with:
>
> courierlogger sends standard output and standard error to syslog, so
> it should be logged.
>
> You should be able to set up a test address with a .courier file that
> echoes something to standard error and then return a non-zero exit
> code. You should be able to see it in your syslog.
>
> Only courierlogger sends anything to syslog. All courier processes
> send output to their standard output and error which is piped to
> courierlogger, which logs it. If you're seeing anything at all, in
> syslog, you should be able to see anything that's emitted to standard
> error.
>
> Certain prefixes do cause each individual syslog message to be logged
> at a different level, such as debug, info, or error. Perhaps your
> syslog configuration is dropping certain classes of messages.

Thank you for steering me in the right direction.
After playing around and digging deeper, I started wondering why I
always have a line with "authlib: groupid=114" in my logs:

Oct 22 11:20:36 stargate courierlocal:
id=00000000021FCE35.000000006534E964.001CBEBB,from=<[email protected]>,addr=<[email protected]>:
maildrop: authlib: groupid=114
Oct 22 11:20:36 stargate courierlocal:
id=00000000021FCE35.000000006534E964.001CBEBB,from=<[email protected]>,addr=<[email protected]>,size=7493,success:
Message delivered.

I never thought much about it, because it was so cryptic. Turns out I
had left this in .courier on an earlier debugging attempt:

|/usr/bin/maildrop -w 90 -V 5 -d <address>

The argument -V 5 logs very much and "authlib: groupid=114" is only the
very first line.

Once I use -V 1 or omit -V, the complete output of maildrop shows up in
syslog. I guess the long maildrop output got truncated somewhere?

>> 2. How can I recover/reset the stuck mailbox in the 456 state. I tried:
>>
>> * cancelmsg the message in the queue.
>> * courier flush
>> * courier clear all
>> * courier clear <mailaddress>
>> * restarted courier
>>
>> None of these worked, and it took some time for the mailbox to start
>> accepting emails again on its own.
>
> courier clear does not immediately redeliver any held mail. It just
> clears the error message, and then the subsequent deliveries, when
> they happen, will proceed.
>
> So the sequence of events should be courier clear, then courier flush.
> Note that with large mail queues courier flush may only flush a subset
> of pending messages, at once.

Curious. Actually, the mail queue was already empty after I canceled the
mail. The 'mailq' command displayed nothing, and the 'msgq' and 'msgs'
directories had only empty directories in them. Still, it took over an
hour for Courier to stop responding with "456 Address temporarily
unavailable" for newly received emails.

"courier show all" showed that the address was blacklisted.

I couldn't clear it with either "courier clear all" or "courier clear
<mailaddress>." "courier show all" still displayed the same address.
However, I don't remember if I had tried to run "courier flush" after
"courier clear" once more.

Thank you,
Norbert

_______________________________________________
courier-users mailing list
[email protected]
Unsubscribe: https://lists.sourceforge.net/lists/listinfo/courier-users