sender-specific AUTH or relayhost
Matthias Andree
> What happens when the user wants to send mail to a local recipient?
> That mail should not be routed to the ISP.
>
> In other words, the user should not have to specify:
>
> /etc/postfix/main.cf:
> sender_transport_maps = whatever:/etc/postfix/sender_transport
> transport_maps = whatever:/etc/postfix/transport
>
> # Send mail from myself through my ISP
> /etc/postfix/sender_transport:
> us...@domain.tld smtp:isp.tld
>
> # Except when mail is addressed to a local user.
> /etc/postfix/transport:
> my.host.name local:
> local.host.name local:
> * :
>
> because that would be too ugly.
Sounds like some form of nesting is needed, for instance putting the
sender_transport_maps on the right hand side of (recipient)
transport_maps. But is that big enough to fit the common applications?
# internal host, accepts all senders without AUTH:
gwaihir.mydomain.example smtp:
# local delivery:
mydomain.example local:
# external delivery:
* sender_routing:hash:/etc/postfix/sender_transport
> There is already some brain damage involved when one wants to
> transform a general-purpose SMTP mail server into something that
> can used on sites that don't have a stable and globally valid
> Internet hostname. I see this not as the fault of SMTP, but rather
> the result of an attempt to stretch SMTP beyond its limits.
It's the insane filters on recipient sites that let us jump these
hoops. First it was spam, then vermin, that made people reject mail from
dialups - and if you have multiple users (freelancers w/ office sharing)
with multiple identities but cannot afford static IP to run your mail
CLIENT [sic!] on. As though your national mail cared into which dropbox
you stuffed your xmas greeting card. (OK, they may separate local from
other destinations, but nevermind.)
>> Not necessarily. If the mail is injected from $mynetworks and is
>> therefore admissible for relay (default config), there is no need to
>> map anything.
>
> These mappings are often needed on sites that don't have a stable
> and globally valid Internet hostname, and/or with ISPs that require
> that the sender domain is in their name space.
Sites without globally valid hostname are not relevant, that problem had
been solved before I came to Postfix in spring 1999.
Sites with ISP matching AUTH against envelope sender are the problematic
cases.
--
Matthias Andree
Encrypt your mail: my GnuPG key ID is 0x052E7D95
Victor....@morganstanley.com
> Sites with ISP matching AUTH against envelope sender are the problematic
> cases.
>
Clearly the ISP is selling the user an MUA service, rather than MTA
service. Why should Postfix work around this? If you want to run an MTA,
use an ISP that offers support for MTAs.
The whole sender routing thing is backwards I think, instead of mapping
the sender to a transport, we should be mapping the transport to a sender!
sender_override_maps = hash:/etc/postfix/sender.bynexthop
Since it is the ISP's policy that all mail sent to them come from the
sender in question, the simplest thing is to route the recipient to
the appropriate transport as usual and then derive a static sender from
the nexthop if listed in sender_override_maps.
The configuration in question is for outbound-only MTAs, so bounces to
external recipients must simply be dropped or redirected into a local
mailbox. It is not OK to replace '<>' with '<cli...@isp.net>' since that
can easily loop.
--
Viktor.
Victor....@morganstanley.com
> The whole sender routing thing is backwards I think, instead of mapping
> the sender to a transport, we should be mapping the transport to a sender!
>
> sender_override_maps = hash:/etc/postfix/sender.bynexthop
>
Note that it be best to enable this option only for a specific clone of
the smtp transport:
master.cf:
isprelay unix ... smtp
-o smtp_sender_override_maps=$isprelay_sender_override_maps
-o fallback_relay=[smtp-otherisp.tld]
main.cf:
isprelay_sender_override_maps = ...
(I am also suggesting the parameter name start with "smtp_").
The advantage of this approach is that mail to the ISP for delivery to
the ISP's users by MX record can be delivered without morphing the sender.
While mail that uses the ISP as a relay via a transport table mapping
(non-MX routing) can use the isprelay transport and then map the sender...
Much cleaner that sender "routing" I think and should work when the
transport specifies a fallback_relay (rewrite the sender per the actual
nexthop).
This said, should Postfix support this misuse of SMTP. The user is asking
his MTA to emulate an MUA, and frankly they should just use an MUA
pointing at the ISP submission host (I don't run an MTA at home even
though my PowerBook running Panther has Postfix on it).
--
Viktor.
Wietse Venema
> On Wed, 5 Nov 2003, Matthias Andree wrote:
>
> > Sites with ISP matching AUTH against envelope sender are the problematic
> > cases.
> >
>
> Clearly the ISP is selling the user an MUA service, rather than MTA
> service. Why should Postfix work around this? If you want to run an MTA,
> use an ISP that offers support for MTAs.
>
> the sender to a transport, we should be mapping the transport to a sender!
>
> sender_override_maps = hash:/etc/postfix/sender.bynexthop
No, think one MTA that is shared by several users. Depending on
the sender, non-local mail needs to be given to the matching ISP,
using the SASL authentication that matches the sender. Multiple
senders can be associated with the same ISP. This is why I proposed
that the SASL password file be indexed with "sender:server".
So all one needs is a sender transport map, an smtp client hack
for delayed nexthop lookup, and some extra syntax for the SASL
password file.
Yes, it's quite perverse to use an MTA for a MUA-oriented service,
and I wonder if the folks who need it really have the skills to
jump all these little hoops.
Wietse
Matthias Andree
> Clearly the ISP is selling the user an MUA service, rather than MTA
> service. Why should Postfix work around this? If you want to run an MTA,
> use an ISP that offers support for MTAs.
That's segregating by financial ressources. I thought the Internet was
supposed to stop such discrimination.
> The whole sender routing thing is backwards I think, instead of mapping
> the sender to a transport, we should be mapping the transport to a
> sender!
Now that's a really funky suggestion, unless I'm missing something
obvious.
> sender_override_maps = hash:/etc/postfix/sender.bynexthop
Suppose I have use...@gmx.de and use...@gmx.de on my machine, then
mapping transports to senders won't work. Same if I have role accounts
or something, then again, the sender is the independent variable that
dominates the delivery process.
Matthias Andree
> On Tue, 4 Nov 2003, Wietse Venema wrote:
>
>> No, think one MTA that is shared by several users. Depending on
>> the sender, non-local mail needs to be given to the matching ISP,
>> using the SASL authentication that matches the sender. Multiple
>> senders can be associated with the same ISP. This is why I proposed
>> that the SASL password file be indexed with "sender:server".
>>
>
> But, one does not need sender routing when sending mail direct to MX,
> since it is only when relaying to third-parties via the ISP that they
> enforce the sender constraints and require authentication.
That's the premise, direct MX routing is suppressed by the recipient
sites.
> So this sort of sender routing is all or nothing, and bounces have
> nowhere to go.
One of the local users will have to be the RHS of the postmaster and
double-bounce aliases.
> Furthermore, when authentication is required why would a multi-user system
> have keys for each of the multiple users trusted to the Postfix SMTP
> client?
Because the ISP requires that.
> The entire market segment for this may be single-user machines.
Nope. Small non-IT businesses, shared offices, with dialup also need
such functionality.
Victor....@morganstanley.com
> Suppose I have use...@gmx.de and use...@gmx.de on my machine, then
> mapping transports to senders won't work. Same if I have role accounts
> or something, then again, the sender is the independent variable that
> dominates the delivery process.
>
Why would both of these user's personal ISP passwords be configured into
Postfix. On a single user machine I can see the user configuring his
password into the MTA. On a multi-user machine this seems much less
likely.
Granted, if the ISP is using Postfix with sender_login_maps, they could
map multiple sender addresses to the same login and password, and the
administrator of the machines can acquire multiple mailboxes associated
with the same account, but then any IMAP or POP access would also likely
share the same password, which the users are unlikely to want.
I just don't see a plausible multi-user configuration in this space when
*authentication* is involved. If the ISP is using *permit_mynetworks*
with egress sender address filtering, then some sort of sender routing may
make sense on multi-user systems, but why don't the users just get a life
and use an MUA!
I have MaCOS X 10.3 at home with Postfix installed on it, but I don't use
it. My home machine is perfectly happy being an MUA only device.
--
Viktor.
Wietse Venema
one personal MUA account with one ISP. The number of different ISPs
may be smaller than the number of different personal MUA accounts.
Non-local mail should be sent via the sender's ISP, using the
sender's SASL authentication info. This is in order to comply with
ISP requirements that sender addresses are within their own name
space.
Why would these people use a local MTA in the first place? They
are using it as some kind of mail proxy between their local MUA
and their ISP's SMTP server. This extra step makes life much more
complicated than when they were connecting directly to the ISP's
SMTP server. Just imagine what a support telephone call would go
like.
The only major benefit I see is the ability to run all mail through
a centralized local spam/virus scanner.
Postfix can be morped into this job by making relay hosts sender
dependent, and by adding a SASL password table that is indexed by
sender:server (the :server part being optional; it just prevents
Postfix from giving the sender's password to anyone in case of an
MTA mis-configuration), and there would have to be a designated
MUA account for sending all the mail that is generated by the MTA
itself (bounces, double bounces, etc.).
All this is significantly more complicated than registering a domain
name and setting up a business account. I seriously doubt if the
people who want multiple ISP accounts per Postfix instance have
the skills to configure it properly.
What is the target audience: home users and student dormitories?
Wietse
Keith Matthews
wie...@porcupine.org (Wietse Venema) wrote:
> Scenario: a site with multiple users. Each "user" or "role" has
> one personal MUA account with one ISP. The number of different ISPs
> may be smaller than the number of different personal MUA accounts.
>
I had a similar situation to this with a client recently. The only
difference was that there was only one ISP although there were 3
'accounts'.
> Non-local mail should be sent via the sender's ISP, using the
> sender's SASL authentication info. This is in order to comply with
> ISP requirements that sender addresses are within their own name
> space.
Difference - no SASL needed - I believe the ISP used something like
pop-b4-smtp. Not crucial to the justification I think, as a different
ISP would quite likely have different rules.
>
> Why would these people use a local MTA in the first place? They
> are using it as some kind of mail proxy between their local MUA
> and their ISP's SMTP server. This extra step makes life much more
> complicated than when they were connecting directly to the ISP's
> SMTP server. Just imagine what a support telephone call would go
> like.
>
The crucial driver in the situation was that there were 2 real people
involved and they accessed mail from 2 different desktop machines. They
needed to know which messages the other had dealt with, and what replies
had been made. To make matters worse one was part-time (mornings only)
and the other tended to be out-and-about a lot.
> The only major benefit I see is the ability to run all mail through
> a centralized local spam/virus scanner.
>
> Postfix can be morped into this job by making relay hosts sender
> dependent, and by adding a SASL password table that is indexed by
> sender:server (the :server part being optional; it just prevents
> Postfix from giving the sender's password to anyone in case of an
> MTA mis-configuration), and there would have to be a designated
> MUA account for sending all the mail that is generated by the MTA
> itself (bounces, double bounces, etc.).
>
Problem I did not have (Thank God - there were enough problems in other
areas). Even version 1.mumble had the facilities to make my setup work,
but it was messy.
> All this is significantly more complicated than registering a domain
> name and setting up a business account.
Agreed, but the business did not want the expense and hassle of
reprinting stationery with email addresses on it (having just had a lot
printed) or (for some reason I could not get them to explain) get the
account redirected.
> I seriously doubt if the
> people who want multiple ISP accounts per Postfix instance have
> the skills to configure it properly.
>
For those who do it themselves you are probably right. I'm trying to
build a business of looking after mail services for SMEs. In particular
I try to get the setup in such a way that 'typical' users have to do
nothing more than switch the box on and call me if things go wrong.
> What is the target audience: home users and student dormitories?
>
SMEs generally do seem to have some requirements that seem very strange
by the standards of large business. That does not make the requirement
any less valid.
Liviu Daia
> Matthias Andree pointed out that there may be an increasing demand for
> per-sender authentication in the Postfix SMTP client.
Aside from the design issues discussed so far, there seem to be
some further complications related to sender spoofing. Unless senders
are authenticated to the local machine first, any user allowed to
relay would be able to authenticate to third party servers with the
the credentials of any other user. IOW, using this feature without
reject_sender_login_mismatch would be a bad idea. This suggests that
the right approach to the above problem would be authentication proxy
rather than per-sender authentication credentials. But implementing
that would require the co-operation of the SASL library.
> While per-sender password support could be hacked into the SMTP
> client's SASL password file, there are a few problems that need
> clearing up before this becomes generally useful:
>
> 1 - Per-sender authentication often requires support for a per-sender
> relay host. This means either extending the transport map user
> interface with an option that says what to use as lookup key, or
> separate sender-transport and recipient-transport map lists, with
> an option to specify if sender-transport lookup happens before or
> after recipient-transport lookups.
Hmm. AFAICT, sender-transport should be applied before
recipient-transport. OTOH, authentication credentials should be chosen
after all transport overrides...
> 2 - Per-sender authentication/relaying would work only for mail
> that is originated by real users. Mail from pseudo-users like
> MAILER-DAEMON to the outside world (think of some mail delivery
> problem) should not be dropped on the floor. The solution would be
> to avoid ever sending mail from pseudo-users like MAILER-DAEMON to
> the outside world.
[...]
I don't understand this. Are there any sites that would not accept
bounces without authentication?
On 3 November 2003, Matthias Andree <m...@dt.e-technik.uni-dortmund.de> wrote:
[...]
> So, what do we need?
>
> a. choose relayhost by sender domain or full sender address, after
> [sender_]canonical_maps
> b. choose SASL credentials by sender domain or full sender address,
> c. functionality to either re-auth in the middle of an SMTP session
> (if permitted by the RFC, I don't know offhand) or functionality to
> separate SMTP sessions by sender.
IIRC that's not allowed.
[...]
> Makes me wonder if per-user saslpasswd files are useful, in analogy to
> .forward - and how these are implemented.
[...]
This seems to be important. It makes sense to allow users to change
their own credentials...
On 3 November 2003, Wietse Venema <wie...@porcupine.org> wrote:
[...]
> What happens when the user wants to send mail to a local recipient?
> That mail should not be routed to the ISP.
>
> In other words, the user should not have to specify:
>
> /etc/postfix/main.cf:
> sender_transport_maps = whatever:/etc/postfix/sender_transport
> transport_maps = whatever:/etc/postfix/transport
>
> # Send mail from myself through my ISP
> /etc/postfix/sender_transport:
> us...@domain.tld smtp:isp.tld
>
> # Except when mail is addressed to a local user.
> /etc/postfix/transport:
> my.host.name local:
> local.host.name local:
> * :
>
> because that would be too ugly.
I don't understand this either. Why can't $mydestination override
transport maps?
[...]
> A table with (sender:server username:password) would be robust
> enough. The :server part can be optional if we have dedicated
> sender_sasl_password files, and would be required with a mixed
> sender/destination sasl_password file.
[...]
I suppose you mean the sender: part can be optional. That would
extend the existing syntax.
On 4 November 2003, <Victor....@morganstanley.com> wrote:
> On Wed, 5 Nov 2003, Matthias Andree wrote:
>
> > Sites with ISP matching AUTH against envelope sender are the
> > problematic cases.
> >
>
> Clearly the ISP is selling the user an MUA service, rather than MTA
> service. Why should Postfix work around this?
FWIW, it seems to me that SMTP AUTH itself was designed with MUA
services in mind, not MTAs.
> If you want to run an MTA, use an ISP that offers support for MTAs.
>
> The whole sender routing thing is backwards I think, instead of
> mapping the sender to a transport, we should be mapping the transport
> to a sender!
>
> sender_override_maps = hash:/etc/postfix/sender.bynexthop
>
> Since it is the ISP's policy that all mail sent to them come from the
> sender in question, the simplest thing is to route the recipient to
> the appropriate transport as usual and then derive a static sender
> from the nexthop if listed in sender_override_maps.
[...]
Not when more than one user want to relay to the same ISP. What if
the named ISP uses the authenticated senders for accounting?
On 4 November 2003, <Victor....@morganstanley.com> wrote:
> Note that it be best to enable this option only for a specific clone
> of the smtp transport:
>
> master.cf:
> isprelay unix ... smtp
> -o smtp_sender_override_maps=$isprelay_sender_override_maps
> -o fallback_relay=[smtp-otherisp.tld]
>
> main.cf:
> isprelay_sender_override_maps = ...
>
> (I am also suggesting the parameter name start with "smtp_").
>
> The advantage of this approach is that mail to the ISP for delivery
> to the ISP's users by MX record can be delivered without morphing the
> sender. While mail that uses the ISP as a relay via a transport table
> mapping (non-MX routing) can use the isprelay transport and then map
> the sender...
[...]
This is so ugly. The way I see it, authentication credentials
should not depend on whether the ISP is the final destination of the
message or not.
Regards,
Liviu Daia
--
Dr. Liviu Daia e-mail: Liviu...@imar.ro
Institute of Mathematics web page: http://www.imar.ro/~daia
of the Romanian Academy PGP key: http://www.imar.ro/~daia/daia.asc
Matthias Andree
> Aside from the design issues discussed so far, there seem to be
> some further complications related to sender spoofing. Unless senders
> are authenticated to the local machine first, any user allowed to
> relay would be able to authenticate to third party servers with the
> the credentials of any other user. IOW, using this feature without
> reject_sender_login_mismatch would be a bad idea. This suggests that
> the right approach to the above problem would be authentication proxy
> rather than per-sender authentication credentials.
Good point.
> I don't understand this. Are there any sites that would not accept
> bounces without authentication?
For relay? Lots of sites. The point of this sender-routing stuff is to
walk around dial-up black lists, and if they don't accept my envelope
sender because I'M on dialup, they'll surely reject a NULL envelope
sender when I'm on dialup.
> FWIW, it seems to me that SMTP AUTH itself was designed with MUA
> services in mind, not MTAs.
I for one am more comfortable with Postfix' logging that with a client's
nonexistant logging.