Szerző: Hans Wilmer Dátum: Címzett: tiefsinn CC: exim-users Tárgy: Re: [Exim] choosing a smarthost depending on header_from
On Thu, Oct 03, 2002 at 07:00:42PM +0200, tiefsinn@??? wrote: > I'm using different pop3-accounts on various providers ( e.g. Msn, Gmx,
> Lycos, Web.de)
> Each of those pop3-servers will only accept mail from a certain From-address
> and with a certain login. I want exim to route my mail to a specific
> smarthost depending on what my MUA put in the From-header.
> example:
> #
> noone@??? --> choose smarthost pop.gmx.de
> someone@??? --> choose smarthost pop3.web.de
Hi,
gmx is very unreliable in the sense of loosing mails while fetching
them with fetchmail. Since gmx is responding very slow or sometimes
not at all, fetchmail is frequently running into broken connections,
and gmx often looses some of your mails on that occassions.
Web.de has an SMTP-after-POP setup that doesn't work, i. e., you
cannot send mail using the SMTP server of web.de to write to
anybody@???. I've been discussing that with their support, but it
turned out that they're not knowing what they're doing at all.
Therefore, I stopped using both gmx.de/gmx.net and
web.de. Sotfhome.net works much better, but all mail service providers
I could find do have serious restrictions on the amount of incoming
mail that can be stored in the mailbox. Softhome.net allows max. 500
mails (there's a size restriction, too); after that limit is reached,
the oldest mails are being deleted --- needless to say that this is
not acceptable. This limit won't last for much more than a single day
for me. Web.de has, afaik, a size limit of only 10 MB --- that won't
last for three days for me.
My overall experience is, that by using the SMTP server of some mail
service provider, the chances that outgoing mail gets lost without any
notice are inacceptably high.
Since you're running your own mail server, there's no need to use any
of the SMTP servers of your mail service providers. Your own mail
server (sendmail, or exim) can send your outgoing mails on its
own. This has the great advantage that you are in full control of your
outgoing mail yourselfe, and it conforms to RFC 821. But it has a
drawback, see below. You should have a name server setup and running
for that, see the DNS-HOWTO how to do that. Setting it up is not as
difficult as it seems, and having a name server makes things easier in
general.
Configuring your MUA to set different From: headers (depending on whom
you're writing to?) is another issue. If I understand it right,
additionally you would have to set up your MTA to rewrite the
envelope-sender of your outgoing mails depending on the From: header
the MTA gets from the MUA. This would be a setup I'd deprecate, if not
for securety reasons, than for the trouble it may cause at least when
several users send mail using your MTA. But making use of
/etc/email-addresses may help you with that?
I've been facing about the same problems you're having now: several
mail accounts, each with its own smarthost and an SMTP-after-POP
setup. As a first approach, I was using always only one address to
send outgoing mail, while fetching incoming mail from different
accounts with fetchmail. Outgoing mail was sent by my MTA most of the
time without using a smarthost. This works nice until it comes to
receiving and sending error messages (about undeliverable mail, for
example): Afair you won't receive bounces because there's no correct
address to send them to, and, when using a smarthost, these stupid
things often do not accept bounces that you (your MTA) wants to send.
But if you're willing to spend a bit of your money, you can solve all
these problems by registering your own domain and by having a
multidrop-mailbox, even with no restriction on the amount of mail that
can be stored in it. You can then configure your system to operate as
if you had a permanent connection to the internet! There's no
noticeable difference. If you're interested in such a setup, feel free
to ask me.
GH
--
This mail is copyrighted material and must not be processed by
closed-source software.