[AMaViS-user] Open relay, non local recip, mail aliasing and forwarding
Violaine Grimly
We are using Postfix+amavisd-new on our server. We have set up virtual domains and virtual aliases, and mail to ab...@doma.in gets forwarded to ef...@other.domain. Nothing really weird, it's been working flawlessly since several years.
We have a dual postfix setup (TCP/25 for external incoming, TCP/587 for internal incoming) and dual paths into amavisd-new (TCP/587 uses a policy bank with 'originating => 1').
With the last version of Amavisd-new (2.6.4), we now get lots of
Open relay? Nonlocal recips but not originating: x...@gmail.com
messages when forwarding incoming mail (from TCP/25) to the proper external addresses.
Maillog contains this :
postfix/qmgr[32400]: E4C641C7227: from=<x...@yahoo.fr>, size=1931, nrcpt=1 (queue active)
amavis[32267]: (32267-01) LMTP::10024 /var/amavis/tmp/amavis-20100216T114405-32267: <x...@yahoo.fr> -> <y...@gmail.com> SIZE=1931 Received: from [127.0.0.1] by localhost (amavisd-new, port 10024) with LMTP for <y...@gmail.com>
amavis[32267]: (32267-01) Checking: w1SWoGIzySiM [217.146.182.34] <x...@yahoo.fr> -> <y...@gmail.com>
amavis[32267]: (32267-01) Open relay? Nonlocal recips but not originating: y...@gmail.com
How should we change our configuration to make those messages go away ?
Tia,
-- Violaine
------------------------------------------------------------------------------
SOLARIS 10 is the OS for Data Centers - provides features such as DTrace,
Predictive Self Healing and Award Winning ZFS. Get Solaris 10 NOW
http://p.sf.net/sfu/solaris-dev2dev
_______________________________________________
AMaViS-user mailing list
AMaVi...@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/amavis-user
AMaViS-FAQ:http://www.amavis.org/amavis-faq.php3
AMaViS-HowTos:http://www.amavis.org/howto/
Jernej Porenta
On Feb 16, 2010, at 11:52 AM, Violaine Grimly wrote:
>
> We have a dual postfix setup (TCP/25 for external incoming, TCP/587 for internal incoming) and dual paths into amavisd-new (TCP/587 uses a policy bank with 'originating => 1').
>
> With the last version of Amavisd-new (2.6.4), we now get lots of
>
> Open relay? Nonlocal recips but not originating: x...@gmail.com
>
> messages when forwarding incoming mail (from TCP/25) to the proper external addresses.
>
> How should we change our configuration to make those messages go away ?
>
We had similar issues and if I remember right it was mynetworks_maps configuration option, that helped us out:
@mynetworks_maps = (read_array('/etc/postfix/mynetworks'), \@mynetworks);
@client_ipaddr_policy = map { $_ => 'MYNETS' } @mynetworks_maps;
I believe that is extensively documented in RELEASE_NOTES for 2.6.4 version, so if my answer does not help you out, then release notes are your way out (and other amavis-user subscribers as well :)).
regards,
--
Jernej Porenta <jernej....@arnes.si>
ARNES, Tehnološki park 18, p.p. 7, SI-1001 Ljubljana, Slovenia
tel: +386 1 479 8800, fax: +386 1 479 88 99
Mark Martinec
> We are using Postfix+amavisd-new on our server. We have set up virtual
> domains and virtual aliases, and mail to ab...@doma.in gets forwarded to
> ef...@other.domain. Nothing really weird, it's been working flawlessly
> since several years.
>
> We have a dual postfix setup (TCP/25 for external incoming, TCP/587 for
> internal incoming) and dual paths into amavisd-new (TCP/587 uses a policy
> bank with 'originating => 1').
>
> With the last version of Amavisd-new (2.6.4), we now get lots of
> Open relay? Nonlocal recips but not originating: x...@gmail.com
> messages when forwarding incoming mail (from TCP/25) to the proper
> external addresses.
It's just a warning that was added, no other changes in that area.
The intention is to remind you that the $originating flag was not set,
probably due to omission in configuration - and that it may do good
to address the issue, as the $originating flag controls aspects
like DKIM signing, adding disclaimers, pen pals, statistics, etc.
> How should we change our configuration to make those messages go away ?
It depends on how you determine that a message is coming from inside
or from authenticated roaming users. For simple installations with no
remote mail submissions it suffices to configure @mynetworks_maps, and,
like Jernej notes, not to forget to re-evaluate the @client_ipaddr_policy
after/if @mynetworks_maps is changed:
@client_ipaddr_policy = map { $_ => 'MYNETS' } @mynetworks_maps;
(this is not necessary if only @mynetworks is changed
but @mynetworks_maps left to its default)
For more complex setups like yours, with dedicated submission port
and dual paths to amavisd, letting it receive originating mail on
a dedicated port, the solution as you already have is needed,
attaching a policy bank with originating => 1 to a TCP port
on which originating mail is arriving.
It seems you already have this set up with this in view, but got
some detail wrong. Check that your message in question really
activated a suitable policy bank, setting the originating => 1.
(assuming of course that the message really originated from your
users)
Mark
Pedro Estevão
This simply stop scanning messages at all, doesn't it?
Since mails received from external are hooked to amavisd internally...