Re: Reply lines with short continuation
Alessandro Vesely <[email protected]>
| Newsgroups | gmane.mail.imap.courier.general |
|---|---|
| Message-ID | <[email protected]> |
Thanks Sam. I fixed my log parser.
Best
Ale
On Thu 28/Mar/2024 22:53:30 +0100 Sam Varshavchik wrote:
> Alessandro Vesely writes:
>
>> Hi Sam,
>>
>> the greylisting module at Debian sends an rcpt temp error like so:
>>
>> 451-Greylisted, see http://postgrey.schweikert.ch/help/debian.org.html
>> 451
>>
>> The terminating line is not logged, perhaps because it's empty. That way,
>> the first line seems to be missing a continuation. Code that collects SMTP
>> replies from the log chokes by bundling all those until it finds a
>> terminator. Not a severe malfunction, just getting snippets like so:
>>
>> 1 451-Greylisted, see http://postgrey.schweikert.ch/help/debian.org.html
>> 451-Greylisted, see http://postgrey.schweikert.ch/help/debian.org.html
>> 451-Greylisted, see http://postgrey.schweikert.ch/help/debian.org.html
>> 550-"JunkMail rejected - wmail.tana.it [94.198.96.74]:54329 is in an
>> RBL, see
>> 550 Error: open resolver;
>> https://check.spamhaus.org/returnc/pub/2400:cb00:684:1024::ac45:cf06/"
>
> I think I've seen this myself. It's very obnoxious behavior: the last sent line
> is a continuation line, then they just close the socket without sending the
> final line of the reply.
>
> Courier should, separately, log a connection error immediately after the last
> line. You should see it in the logs. If that's the case it won't be too
> difficult to synthesize a fake final line, as a logged substitute.
>
> However, I think this is ultimately a lost cause. This isn't the only way that
> a malformed SMTP reply can get logged. Courier will accurately reflect whatever
> it gets, and then handle the rejection since it all boils down to only a soft
> or a hard error, and the actual content of the error is irrelevant. The first
> character of the first line of the error message drives the decision, and
> that's going to be the end of it.
>
> Any log parsers should really be prepared to handle anything.
>
> diff --git a/courier/courier/module.esmtp/libesmtp.c
> b/courier/courier/module.esmtp/libesmtp.c
> index 93f18c4..6b047fe 100644
> --- a/courier/courier/module.esmtp/libesmtp.c
> +++ b/courier/courier/module.esmtp/libesmtp.c
> @@ -1839,7 +1839,11 @@ static int esmtp_parsereply(struct esmtp_info *info,
> const char *cmd,
> void *arg)
> {
> - const char *p;
> + const char *p, *q;
> + char *r;
> +
> + char conn_closed_error[]="500 connection closed by remote host.";
> + int i;
>
> if ((p=esmtp_readline(info)) == 0)
> {
> @@ -1848,6 +1852,17 @@ static int esmtp_parsereply(struct esmtp_info *info,
> return (-1);
> }
>
> + r=conn_closed_error;
> + q=p;
> +
> + for (i=0; i<3; ++i)
> + {
> + if (*q >= 0 && *q <= 9)
> + {
> + *r++=*q++;
> + }
> + }
> +
> switch (*p) {
> case '1':
> case '2':
> @@ -1861,6 +1876,9 @@ static int esmtp_parsereply(struct esmtp_info *info,
>
> if ((p=esmtp_readline(info)) == 0)
> {
> + p=conn_closed_error;
> +
> + (*info->log_smtp_error)(info, p, *p, arg);
> connect_error(info, arg);
> esmtp_disconnect(info);
> return (-1);
>
>
>
> _______________________________________________
> courier-users mailing list
> [email protected]
> Unsubscribe: https://lists.sourceforge.net/lists/listinfo/courier-users
_______________________________________________
courier-users mailing list
[email protected]
Unsubscribe: https://lists.sourceforge.net/lists/listinfo/courier-users