1. Forum
  2. Usenet
  3. COMP.MAIL.SENDMAIL

  • Bug report - fails to log multi-line errors and warnings properly (trun

    From Chris Drake@21:1/5 to All on Wed May 5 15:21:56 2021
    I see this in debug:-

    RCPT To:<*@gmail.com>
    DATA
    452-4.2.2 The email account that you tried to reach is over quota. Please direct
    452-4.2.2 the recipient to
    452 4.2.2 https://support.google.com/mail/?p=OverQuotaTemp e14si598114pgu.152 - gsmtp
    <*@gmail.com>... Deferred: 452-4.2.2 The email account that you tried to reach is over quota. Please direct

    But only this in the logs:
    May 5 22:19:28 smtp sendmail[2556204]: 1459Dm7f1597664: to=<*@gmail.com>, ctladdr=<*@*.com> (515/515), delay=13:05:40, xdelay=00:00:06, mailer=esmtp, pri=128738802, relay=alt4.gmail-smtp-in.l.google.com. [74.125.200.26], dsn=4.2.2, reply=452-4.2.2 The
    email account that you tried to reach is over quota. Please direct, stat=Deferred: 452-4.2.2 The email account that you tried to reach is over quota. Please direct

    The most important part of the error response is missing from the logs.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Claus =?iso-8859-1?Q?A=DFmann?= @21:1/5 to Chris Drake on Thu May 6 06:06:14 2021
    Chris Drake wrote:

    452-4.2.2 The email account that you tried to reach is over quota. Please direct
    452-4.2.2 the recipient to
    452 4.2.2 https://support.google.com/mail/?p=OverQuotaTemp e14si598114pgu.152 - gsmtp
    <*@gmail.com>... Deferred: 452-4.2.2 The email account that you tried to reach is
    over quota. Please direct

    But only this in the logs:
    pri=128738802, relay=alt4.gmail-smtp-in.l.google.com. [74.125.200.26], dsn=4.2.2,
    reply=452-4.2.2 The email account that you tried to reach is over quota. Please
    direct, stat=Deferred: 452-4.2.2 The email account that you tried to reach is over
    quota. Please direct

    The most important part of the error response is missing from the logs.

    Obviously an MTA needs to impose limits on the amount of data it logs
    -- a (bogus) server might send thousands of lines as reply.
    The limit in sendmail is STATLEN in deliver.c.
    If your syslog() implementation can handle it, you could increase
    that value and see what happens.


    --
    Note: please read the netiquette before posting. I will almost never
    reply to top-postings which include a full copy of the previous
    article(s) at the end because it's annoying, shows that the poster
    is too lazy to trim his article, and it's wasting the time of all readers.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Grant Taylor@21:1/5 to All on Thu May 6 10:01:49 2021
    On 5/6/21 12:06 AM, Claus Aßmann wrote:
    Obviously an MTA needs to impose limits on the amount of data it logs
    -- a (bogus) server might send thousands of lines as reply.

    Agreed.

    Do you know off hand if the full error is included in the eventual DSN
    that Sendmail will send -- by default -- to the envelope sender?



    --
    Grant. . . .
    unix || die

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Henning Hucke@21:1/5 to ml+sendmail@esmtp.org on Fri May 7 06:10:38 2021
    On 2021-05-06, Claus Aßmann <ml+sendmail@esmtp.org> wrote:

    Hi Claus,

    Chris Drake wrote:

    452-4.2.2 The email account that you tried to reach is over quota. Please direct
    452-4.2.2 the recipient to
    452 4.2.2 https://support.google.com/mail/?p=OverQuotaTemp e14si598114pgu.152 - gsmtp
    <*@gmail.com>... Deferred: 452-4.2.2 The email account that you tried to reach is
    over quota. Please direct
    [...]

    Obviously an MTA needs to impose limits on the amount of data it logs
    -- a (bogus) server might send thousands of lines as reply.
    The limit in sendmail is STATLEN in deliver.c.
    If your syslog() implementation can handle it, you could increase
    that value and see what happens.

    on the other hand the RFCs clearly state that these are *folded* lines
    so you clould reintegrate the multiple lines into one and impose limits
    on this single line - for instance by limiting the line length to what
    fits into a single UDP packet (for the case that it is sent via
    classical syslog) and overread the rest.

    Best regards,
    Henning Hucke
    --
    How many bits would a BitBlit blit if a BitBlit could blit bits?
    -- macanespie@waves.pas.ti.com in <1993Nov16.130625.1@waves.pas.ti.com>

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Claus =?iso-8859-1?Q?A=DFmann?= @21:1/5 to Henning Hucke on Fri May 7 09:11:47 2021
    Henning Hucke wrote:

    452-4.2.2 The email account that you tried to reach is over quota. Please direct
    452-4.2.2 the recipient to
    452 4.2.2 https://support.google.com/mail/?p=OverQuotaTemp e14si598114pgu.152 - gsmtp
    <*@gmail.com>... Deferred: 452-4.2.2 The email account that you tried to reach is
    over quota. Please direct

    on the other hand the RFCs clearly state that these are *folded* lines

    Can you please tell me which RFC talks about "folded" lines wrt
    "Simple Mail Transfer Protocol"?

    Folding is mentioned in "Internet Message Format",
    but that does not apply here (AFAICT).

    --
    Note: please read the netiquette before posting. I will almost never
    reply to top-postings which include a full copy of the previous
    article(s) at the end because it's annoying, shows that the poster
    is too lazy to trim his article, and it's wasting the time of all readers.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Claus =?iso-8859-1?Q?A=DFmann?= @21:1/5 to Chris Drake on Fri May 7 19:35:02 2021
    Chris Drake wrote:

    452-4.2.2 The email account that you tried to reach is over quota. Please direct
    452-4.2.2 the recipient to
    452 4.2.2 https://support.google.com/mail/?p=OverQuotaTemp e14si598114pgu.152 - gsmtp
    <*@gmail.com>... Deferred: 452-4.2.2 The email account that you tried to reach is
    over quota. Please direct

    But only this in the logs:
    [first line only]

    Maybe try this patch -- it's just a hack and barely tested -- use
    at your own risk etc...
    Let me know if it works.

    diff --git a/sendmail/usersmtp.c b/sendmail/usersmtp.c
    index 1ec64ea..cbb7e0c 100644
    --- a/sendmail/usersmtp.c
    +++ b/sendmail/usersmtp.c
    @@ -3407,6 +3407,26 @@ reply(m, mci, e, timeout, pfunc, enhstat, rtype)
    , rtype, e->e_text);
    }
    }
    +#if _FFR_REPLY_MULTILINE
    + if ((REPLYTYPE(r) > 3 && !firstline && e->e_text != NULL &&
    + rtype != XS_QUIT) || tTd(87, 101))
    + {
    + int len;
    + char *new;
    +
    + /* skip the same stuff or use o? */
    + /* but o is a local variable in the block above */
    + len = strlen(e->e_text) + strlen(bufp) + 3;
    + if (len < 1024 /* XXX proper limit? */
    + && (new = (char *) sm_rpool_malloc(e->e_rpool, len))
    + != NULL)
    + {
    + sm_strlcpyn(new, len, 3, e->e_text, "; ",
    + bufp /* + o */);
    + e->e_text = new;
    + }
    + }
    +#endif /* _FFR_REPLY_MULTILINE */

    firstline = false;

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Grant Taylor@21:1/5 to Henning Hucke on Fri May 7 14:13:53 2021
    On 5/7/21 12:10 AM, Henning Hucke wrote:
    on the other hand the RFCs clearly state that these are *folded* lines
    so you clould reintegrate the multiple lines into one and impose limits
    on this single line

    Why would you do that?

    The only line length limits I recall seeing are related to how long a
    given line can be as transmitted. This seems to apply to the folded
    form, not the unfolded / aggregate line length.

    for instance by limiting the line length to what fits into a single
    UDP packet (for the case that it is sent via classical syslog) and
    overread the rest.

    I remember (tell of) a time when UDP didn't like packets longer than 512
    bytes. I believe the SMTP line length is 1000 characters, including the trailing <CR><LF>. So ... it seems like it would be trivial to exceed
    the 512 byte limit of UDP of old.

    Thankfully these are completely unrelated things and don't need to be
    made to work together. Much like how loud I type and how much weight
    you can carry up a flight of stairs.



    --
    Grant. . . .
    unix || die

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Henning Hucke@21:1/5 to ml+sendmail@esmtp.org on Sat May 8 18:59:04 2021
    On 2021-05-07, Claus Aßmann <ml+sendmail@esmtp.org> wrote:

    Hi Claus,

    Henning Hucke wrote:

    452-4.2.2 The email account that you tried to reach is over quota. Please direct
    452-4.2.2 the recipient to
    452 4.2.2 https://support.google.com/mail/?p=OverQuotaTemp e14si598114pgu.152 - gsmtp
    <*@gmail.com>... Deferred: 452-4.2.2 The email account that you tried to reach is
    over quota. Please direct

    on the other hand the RFCs clearly state that these are *folded* lines

    Can you please tell me which RFC talks about "folded" lines wrt
    "Simple Mail Transfer Protocol"?

    Folding is mentioned in "Internet Message Format",
    but that does not apply here (AFAICT).

    possibly I formulated in a sloppy way.

    RFC 5321 page 49 speaks about a "multi line reply" and states an example
    which uses the "dash space" between the reply code and the message to
    indicate that a reply is not yet complete.

    In a sloppy kind of way I understand this as "folding" or more precise:
    as the protocol way to fold a message into multiple lines.

    Since this kind of reply is in the end a whole I rate it as legit to
    want this to show up as such in the longs instead of being spread
    accross multiple log lines.

    Best regards
    Henning Hucke
    --
    Forecast, n:
    A prediction of the future, based on the past, for
    which the forecaster demands payment in the present.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Grant Taylor@21:1/5 to Henning Hucke on Sat May 8 19:58:22 2021
    On 5/8/21 12:59 PM, Henning Hucke wrote:
    RFC 5321 page 49 speaks about a "multi line reply" and states an
    example which uses the "dash space" between the reply code and the
    message to indicate that a reply is not yet complete.

    In a sloppy kind of way I understand this as "folding" or more precise:
    as the protocol way to fold a message into multiple lines.

    Oy vey! Term collision! (At least for me.)

    I now understand that when you say "message", you are talking about the
    SMTP response message. Not the content that is sent as part of the DATA
    phase.

    I now understand that when you say "folding", you are referring to a
    multi-line SMTP response.

    *blink*

    I can see how those two disparate things can use similar terms. But ...
    wow ... I did not realize that until reading the message that I'm
    replying to. I really thought you were talking about something in the
    content of the DATA phase.

    Since this kind of reply is in the end a whole I rate it as legit
    to want this to show up as such in the longs instead of being spread
    accross multiple log lines.

    You're asking for Sendmail to unwrap multi-line SMTP replies and log
    them as a single line. Correct?



    --
    Grant. . . .
    unix || die

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Henning Hucke@21:1/5 to Grant Taylor on Sun May 9 19:13:42 2021
    On 2021-05-09, Grant Taylor <gtaylor@tnetconsulting.net> wrote:

    Hi Grant,

    [...]
    I now understand that when you say "message", you are talking about the
    SMTP response message. Not the content that is sent as part of the DATA phase.

    I now understand that when you say "folding", you are referring to a multi-line SMTP response.

    mind the thread subject...

    [...]
    Since this kind of reply is in the end a whole I rate it as legit
    to want this to show up as such in the longs instead of being spread
    accross multiple log lines.

    You're asking for Sendmail to unwrap multi-line SMTP replies and log
    them as a single line. Correct?

    I expose my/an opinion about the original content of this thread...

    Best regards,
    Henning Hucke
    --
    Honesty is for the most part less profitable than dishonesty.
    -- Plato

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)