RE: [Exim] Masquerade needed for outbound mail.

Inizio della pagina
Delete this message
Reply to this message
Autore: Kevin Reed
Data:  
To: exim-users
Oggetto: RE: [Exim] Masquerade needed for outbound mail.
Philip Hazel said...
>
> On Thu, 14 Aug 2003, Kevin Reed wrote:
>
> > Find for now...
> >
> >  smarthost_smtp:
> >       driver = smtp
> >       headers_rewrite = *@*.my.domain $1@???
> >       return_path = MAILER-DAEMON@???

>
> Are you sure you want all return paths to be MAILER-DAEMON?
> That means all bounces will come to that account, not to the
> original sender.


For the time being... That is what the original server was doing... Kinda
amazing considering how many unix hosts actually send mail that gets outside
the internal network. Must be a ton of bounces that end up in the bit
bucket with no notification anything failed.

I was forced to switch back to the old Sendmail config today due to this
issue though.. Mail was getting rejected offsite due to the hostnames being
unknown to the world.

The whole methodology here is screwed up though... The mascarading really
should be done at the box this one hands off to for outbound mail but for
some reason doesn't. The box above doesn't even attempt to mascarade this
domain, but at the same times knows all the hosts involved and actually has
direct mail communcation with some of them bypassing this host completely.
Means that those hosts could send mail that gets outside without
mascarading.. Really strange..

In anycase, I just want to get the Exim back up and online. It already does
a lot of things better than the old Sendmail config, produces better logs
and appears to be a lot faster. I will take time and figure a better way to
do this afte things cool down a bit. Its hard to think when someones
breathing down your neck.

> With a bit of messing around with expanded strings, you could
> test $return_path to see if it was of the form
> *@*.your.domain, and then rewrite it as *@your.domain, which
> is what I thought you really wanted.


Yes, that would be preferred...

> Sorry, I haven't time to work out the exact expansion string
> at the moment. You would need to use a regular expression match.


I'll probably take a look at it again closer this weekend...

Besides you have been busy... The new version you released will come in
handy... I think you added the ability to ensure case insensitivity with
hostname matching... That is an issue I will need to deal ...

Thanks for your help, work and dedication...