postfix-users@postfix.org wrote in
<zphqluz8nbsld...@chardros.imrryr.org>:
|On Fri, Jul 12, 2024 at 07:10:41PM +0200, Steffen Nurpmeso wrote:
|> postfix-users@postfix.org wrote in
|> <zpb-edlgah-vs...@chardros.imrryr.org>:
|>|On Fri, Jul 12, 2024 at 01:54:38AM +0200, Steffen Nurpmeso wrote:
|> ...
|>|No, there is no scenario in which no limit is better than an explicit
|>|maximum.
|>|
|>|>|> Letting aside the "extended MAIL" client command that i never have
|>|>|> seen, what i would hope for would be that postfix simply says
|>|>|>
|>|>|> 250-SIZE
|>|>|
|>|>|There's little to gain by doing that. Instead, just advertise the
|>|>|absolute ceiling.
|>|>
|>|> The problem is that the ceiling is too low.
|>|
|>|You're not paying attention, the limit to advertise is the *largest*
|>|message size (not the typical) that you might accept from any source,
|>|to any recipient. Your policy service can then enforce lower limits
|>|for the majority of deliveries.
|>
|> Now you are joking, are you.
|
|So, you really weren't paying attention. :-( I am quite serious.
|
|The words "limit" and "ceiling" are to be read at their actual meaning
|of absolute maxima. Your proposal of "250-SIZE<CRLF>" is essentially an
|advertised infinite limit, but there's no good reason to do that.
I would have in turn thought what the RFC says.
The numeric parameter to the EHLO SIZE keyword is optional. If the
parameter is omitted entirely it indicates that the server does not
advertise a fixed maximum message size. A server that returns the
This.
SIZE keyword with no parameter in response to the EHLO command may
not issue a positive (250) response to an extended MAIL command
containing a SIZE specification without first checking to see if
sufficient resources are available to transfer a message of the
declared size, and to retain it in stable storage until it can be
relayed or delivered to its recipients. If possible, the server
I would assume nothing changes on the postfix side at all.
should actually reserve sufficient storage space to transfer the
message.
And before the RFC says
(3) one optional parameter is allowed with this EHLO keyword value, a
decimal number indicating the fixed maximum message size in bytes
that the server will accept. The syntax of the parameter is as
follows, using the augmented BNF notation of [2]:
size-param ::= [1*DIGIT]
A parameter value of 0 (zero) indicates that no fixed maximum
message size is in force. If the parameter is omitted no
information is conveyed about the server's fixed maximum message
size;
This not.
|Whatever the actual absolute maximum is, advertise that, and enforce the
|target limit for any messages from "typical" senders, who don't get the
|absolute limit. If this does not mesh with your intuition, chalk it up
|to your intution leading you astray, happens to all of us now and
|then...
You're off man, really. RFC 1870 announcement without fix limit
says that the extension is present and the 552 (could) mean(s)
what RFC 1870 says, but that there is not fixed limit.
(In sofar i should look whether there is an errata on the word
"fixed" in the 552 reply code, as it does not make sense.)
I mean, you know, it also knows about per-recipient size
excessment, does it.
And like i said, in times where the IETF warps the word
"reputation" from the one-hop of DKIM and such (i quoted the RFC
number) over many many corners (ARC etc), which is a very strange
thing to do, to say the least, it seems totally square to have
a 10 MB or more limit, but then kick out practically all messages
far below this limit. The only good thing in this regard is that
"practically all" will not be true in the communication i have,
but it could be true in other channels where people per se attach
images and other things etc etc etc etc. But if i implement
anything to handle the case in question, then it should be
somewhat generic, and your thing does not work out at all, that
much is plain.
Having said that, maybe the big ones who make those
neuro-interlinks in between all the states, all over the world, do
not (yet) put that much value into SIZE-caused 552 rejections,
even it affects a large percent value of all message that are sent
to a single receiving MTA. But they could start doing so.
It would make sense for them if they do not use the SIZE extension
and send a size "estimation" pre-flight.
--steffen
|
|Der Kragenbaer, The moon bear,
|der holt sich munter he cheerfully and one by one
|einen nach dem anderen runter wa.ks himself off
|(By Robert Gernhardt)
_______________________________________________
Postfix-users mailing list -- postfix-users@postfix.org
To unsubscribe send an email to postfix-users-le...@postfix.org
