Wietse Venema via Postfix-devel wrote in
<[email protected]>:
|Steffen Nurpmeso via Postfix-devel:
|> I would like to ask whether there is any possibility to access the
|> actual features announced by connected SMTP software?
|> Beyond what is made available as "cipher" etc. i mean.
|
|If you are referring to limits announced by the Postfix SMTP server,
|what Milter macro names did you have in mind for the SMTP server
|to Milter communication?
|
|> I mean, in general, what would be somehow nice is access to
|> limits, of "us" but also of the peer, as possibly announced via
|> RFC 9422 support.
|
|If you are referring to limits received by the Postfix SMTP client,
|then there is no Milter functionality there.
I did not really think, it was just a balloon, so to say. Looking
at MILTER_README (and milter-protocol.txt) the names {daemon_250}
(always, oh no; better only CONNECT, how odd it is), and, well,
the invented {peer_250} (HELO, .. if possible) come to mind.
Having the informations available would surely be beneficial at
times. Especially limits (as a guideline), and DSN, i would think
for myself now.
What really drives me despite the thread's subject: the
capability to "splice" messages directly within the milter, that
would be great; ie, a new directive that would state that any
accept[/reject] action after SMFIC_BODYEOB does not, actually,
"Reset state to before SMFIC_MAIL and continue, unless connection
is dropped by MTA", but instead keeps the current session alive
until two "accept[/reject]" actions happen successively (or a new
not yet existing command is issued). accept/reject at any other
state remains "normal".
The new DKIM, whatever it will be, etc etc, they will require
splicing of messages on a per-envelope-recipient-domain level.
For now you either have to exec for example sendmail(1) with a
recipient subset, or open a socket connection to some submission
or whatever service. This is very expensive, and potentially
insecure (normal users could access the same service), and so
needlessly so.
And you need to take care on milter chains, on egress a signature
creator should usually be last (i would think), so if you splice
at that point in time, other milters may have performed
modifications already, so you may need a dedicated service to
bypass all that.
(Then again, if you can configure only one milter chain, you
likely have one signature thing at the front, to verify signatures
before modifications happen, on ingress, and one last, to create
signatures, on egress. Then the ingress thing can perform the
splice if, in fact, it is "running on egress".)
Maybe, if such a thing would come, a reject would no longer be
possible after the first accept has been issued (a reject would
stop the entire machinery); the first issued "message instance
state" would be reported back .. or whatever.
--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-devel mailing list -- [email protected]
To unsubscribe send an email to [email protected]
