Subject: Re: Multiple smarthosts for SMTP (sending from different accounts)
To: Brian de Alwis <bsd@cs.ubc.ca>
From: Steven M. Bellovin <smb@research.att.com>
List: netbsd-users
Date: 01/29/2002 19:53:17
In message <20020129155203.A13320@slab.gascol.cs.ubc.ca>, Brian de Alwis writes
:
>I have a laptop from which I use fetchmail from my UBC CS account,
>and from which I respond to mail while offline.  Because I connect
>to the 'net from different locations (thus having different FQDNs),
>I had problems sending e-mail as other hosts wouldn't allow relaying
>(my domain not matching the delivering address I guess). So I now
>have sendmail configured to use my department's SMTP server (smtp.cs.ubc.ca)
>as a smarthost via an ssh tunnel. This has worked beautifully so far.
>
>But I may soon have another non-department account from which to
>send and receive e-mail.  Since this is not a department account,
>the dept server won't allow relaying for it. And the other
>account's server similarly won't allow relaying for my department
>address.  So I'll no longer be able to use a single smarthost.
>
>What I really seem to need is some way of having different smarthosts
>depending on the sending address.  Can sendmail do this? Or qmail/etc.?
>Or is there a better solution entirely? (I have no control over the
>SMTP server software). I haven't seen anything so far.
>
>I'm using mutt as my MUA; I'd rather not change if I can manage it.

I think you're ok with what you're doing.  Anti-relay provisions don't 
make decisions based on source address -- that's too easily spoofed -- 
but on where the mail arrived.  

I also use an ssh tunnel, and tell postfix to send to port 20025 on 
127.0.0.1.  That port, in turn, is forwarded to port 25 on the mail 
server.  (It would probably work to go to 127.0.0.1, if you're tunneled 
to the mail server.)  The point is that my tunnel endpoint is trusted 
by the smtp server, based on IP address.

		--Steve Bellovin, http://www.research.att.com/~smb
		Full text of "Firewalls" book now at http://www.wilyhacker.com