postfix-users@postfix.org wrote in <zo8zetk9ax2ci...@chardros.imrryr.org>: |On Wed, Jul 10, 2024 at 07:44:05PM +0200, Steffen Nurpmeso via Postfix-u\ |sers wrote: |> Well, i do not know, .. but i have |> |> message_size_limit = 500000 | |Wow, that's rather restrictive in age when disk capacities are starting |to be measured in 10s of terabytes, while the majority of mail servers |already allowed ~10MB back when 10s of Gigabytes was a plausible disk |size. Do you do a lot of time-travel to the 1990's? :-)
I mean i am not a business, or a nerd that has all the applications and hardware ready at hand, and configured, to support a thousand persons, but is single or only has a small family, or something. This limit is hardly excessed for the communication i have. And if, it is practically always spam (or was, once i created it.) Except for fewest desired messages with PDFs or images. And yes, postfix has a dedicated spool disk partition on the virtual server where it lives, and that would be a bit stingy if the limit is much larger, and spam gets through. Having said that, even with the limit above, a couple of thousand spam messaged could result in a disk full. I would have to re-setup the entire server VM to improve that situation. (Unchanged for almost nine years.) Anyhow with the default limit the number would be dramatically lower. And i mean, i will never forget that administrator on some FreeBSD list stating that the mailbox of his boss has reached a million messages, and that he needs "Archaeopterix" (or so) to index it (whatever that program does). "It is no fun", he said. Thinking about it, i need a better plan against possible attack scenarios even with 500000. Personally, except for the fact that i do not have the video collection (i would go for), i have weeks (or months) of music, lots of coding books etc etc, and certain VMs (again, but many elder missing and to be recreated), and i am below 140 GB. (With more VMs and with video collection i could maybe exceed 512 GB. If i would use flac not Ogg Vorbis, and keep more streams etc etc of videos, maybe really a terabyte. That is wow! A terabyte!! That is sheer grazy. Regarding music etc and all that i think it is a pity, the artwork of albums, the wholisticism of albums, etc, it vanishs. Which is why i do not care, i have CDs etc, and on the computer the quality is good enough. Books i cannot even read on a screen, i need the Haptik, the look and feel of paperworks. Etcetcetc. | https://commons.wikimedia.org/wiki/File:Hard_drive_capacity_over_time.p\ | ng But not here. |> (Btw, does the client part of RFC 1870 actually exist in practice? | |Yes, definitely. Many (though not all) sending MTAs use | | MAIL FROM:<envelope-sender> SIZE=... | |and bounce the large messages over the declared size limit without even |sending "MAIL FROM:" when the size limit in the EHLO response is |smaller. Oh yes? Ok.. but this is not true for the Unix command line and terminal mail clients, for sure, and that is the world i live in. I did not know that. |> I cannot recall to have seen it. Does postfix log such client |> declarations? Would not think it does..) | |No, the client's "MAIL FROM" is not logged at that level of detail, only |the envelope sender is logged by the queue manager when messages enter |the active queue, and by that time it may already have been rewritten. |> |> I have a problem in that I would like several senders to be able |> to send larger messages. | |You may as well advertise the largest supported size, it is better |better than advertising just "SIZE", because clients that honour |"SIZE=<limit>", but don't send "SIZE=" in mail from will be able to |avoid attemting transmission of overly large messages. But not if the largest size is 500000. I would assume that if 250-SIZE is reported, a smart(er than mine) mail client would take more useful steps in case of 5.* than if not. Ie, it could give users some feedback that it otherwise could (or would) not. |> 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. But it definitely is the ceiling, except for fewest (once that is implemented). |> and would then have something like a lookup table that allows to |> configure the actually used size limit based upon senders. |> Is this somehow doable? | |That's where your policy service comes in. It can check the envelope |sender address and act accordingly. Perform the check both in: |smtpd_data_restrictions and smtpd_end_of_data_restrictions. The |former will check any "SIZE=" value promised by the client, while |the latter will check the actual received message size. 'Will likely write a policy server. |Postfix has no built-in sender-specific size enforcement, and none is |needed, given the policy service mechanism. IIRC milters get to see |the full extended "MAIL FROM" command, and the message content, so |you can probably use a milter if you prefer, but a policy service |feels simpler. Yes it does, i thought yesterday i maybe take the opportunity to write a real lua thing. Or i strip postgray to the absolute minimum. But i object the "none is needed", or say, i would for sure if at that early stage the verified hostname is available. Because, i would need two distinct email addresses and servers to make a distinction in between the ones, and the (unknown, mostly) others. And milter or policy, these are expensive externals that need to be driven. (Even as system services if not via spawn, and that is then two processes, at least.) --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
