On Wed, Nov 23, 2011 at 09:11:55AM -0500, Wietse Venema wrote:
> To make per-recipient end-of-data replies useful with Postfix, PRDR
> would need to be supported by at least one third-party content
> inspection mechanism (such as Amavisd-new or Milter), because I see
> no obvious user interface for PRDR with Postfix header/body_checks.
My concern is that there is no obvious mechanism by which one may
determine that a transparent (formerly) SMTP proxy filter is actually
ready to support PRDR. Certainly the filters of this type that I wrote
just try to be very minimal in their SMTP parsing and just pass commands
and replies back and forth and *do not* attempt to trim the EHLO feature
list announced by the destination server. These would definitely breack
very badly if PRDR were enabled in the SMTP session they are proxying.
Likewise, some installations use transparent SMTP proxies in front
of Postfix, and these would likely also break.
In short, I think that PRDR cannot be enabled by default without explicit
assurance from the administrator that nothing directly in front-of
Postfix or a transparent proxy behind it will break as a result.
Likewise, in the outbound direction, one needs to assert that is
one not behind a transparent man-in-the-middle outbound filter.
Otherwise, it is risky to enable PRDR on SMTP client MTAs.
If the feature is not enabled by default in either direction, and
administrators explicitly consent to enable PRDR explicitly in each
direction, then its implementation will be safe to include for use
at those sites that are able to turn it on.
It seems to me that the fraction of clients that will turn on PRDR
will be small enough for a long time to make the net benefit rather
marginal for quite some time.
Adoption would be higher if PRDR could be enabled by default in
client SMTP implementations, but I am concerned that this is not
safe across firewalls, MITM systems, ...
So my view is this is not worth the trouble, as it is too incompatible
with the deployed infrastructure, and does not always know which
SMTP inspecting devices lie along the transmission path.
--
Viktor.
