Rainer Frey (Inxmail GmbH):
> Hi Wietse,
>
> thanks for addressing this issue, a scaling solution for this problem will be
> really appreciated.
>
> We are an E-Mail Marketing provider and offer a hosted solution for a broad
> customer base for which we want to be able separate the reputation (so
> individual customers can take part in reputation systems for content
> originators as opposed to sending servers, and those often require dedicated
> IP addresses).
>
> On Sunday 22 November 2009 16:42:41 Wietse Venema wrote:
> > Finally, this is not the only way source IP address selection can
> > be implemented.
> [...]
> > 3) New access/header_checks/body_checks actions that set an SMTPSOURCE
> > attribute and that is used only by the SMTP client. This decouples
> > source IP address selection from the sender envelope address,
> > and requires no transport selection.
>
> As a user with limited knowledge of the internal infrastructure of Postfix, I
> like this option best. For my understanding, outgoing SMTP configuration
> parameters and mail routing are logically separate concerns, and it is easier
> to understand if these are configured separately.
>
> More important, we need to tune other parameters (destination concurrency,
> timeouts, ...) based on the recipient domain. So only a way of combining
> sender and recipient specific configuration solves our problem completely.
> This option 3) seems to offer the greatest flexibility in this regard.
I notice that you mention other SMTP client settings (HELO name)
that would also need to vary in addition to the source IP address.
And when there are two now, then there will be more later.
This is a good reason for me to avoid introducing a whole new set
of override mechanisms that duplicate the controls that already
exist (override local IP address, override HELO hostname, and the
things that other people will need in the future).
Right now, Postfix provides an override mechanism via master.cf
settings that give access to all the main.cf parameters that control
that particular process. The downside is that this works at the
granularity of transports, but the benefit is that all the parameters
are already implemented (it reuses both code and user experience).
I don't really buy that you need a global scheduler to balance load
that's being sent from different IP addresses to the same sites.
Such balancing is also not happening between independent MTAs. As
long as Postfix does not worse than a bunch of independent MTAs
then it is good enough.
The problem with a general-purpose system like Postfix is that it
can never be optimal for every possible scenario. Optimize too
much in one direction and I end up paying a large price later
when some functionality needs to be added. If there are a bazillion
ways to do X then I have to make the new functionality work with
all those ways, because software with exceptions is a source of
frustration.
Wietse
> > Feature 3) while it appears straightforward, it also completely
> > ignores the existing infrastructure of transport and nexthop
> > selection.
>
> Which, as said above, can be seen as a good thing from a user perspective.
>
> > It has the appeal of a short-sighted^h^h^h^h^h^h^hterm
> > solution and needs more analysis to understand its implications.
>
> One thing that comes to my mind: there are anti-spam measures that want the
> reverse lookup of the sending IP address to correspond with the SMTP HELO
> hostname. I know that this is not required by any standards, but some
> providers use such rules to at least give bad score to non-complying senders.
> An example is UCEProtect, which is used quite often in some parts of Germany.
> Therefore it would be necessary (or at least desirable) to not only select
> the source address, but also the HELO name.
> >
> > Wietse
>
> Rainer
> --
> Software Developer
>
> ------------------------------------------------------
>
> Inxmail GmbH
> Wentzingerstr. 21, 79106 Freiburg, Germany
> Tel: +49 761 296979-0, Fax: -9
> rainer.f...@inxmail.de, www.inxmail.de
>
> Handelsregister Freiburg, HRB 5870
> Ust.-ID: DE198371679
> Gesch?ftsleitung: Martin Bucher, Peter Ziras
>
>
