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.

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.

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

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>

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.

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;

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

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.

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

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