Failing to bypass outgoing emails: Can't connect to TCP port 10024 on 10026

[Gary V]

On 3/27/11, Loic Condette <yanek at altern.org> wrote:
>
>> On 3/24/11, Loic Condette <yanek at altern.org> wrote:
>>> Hello all,
>>>
>>> Sorry if this has been answered before (it probably has, but, AFAIK,
>>> there's no way to search the list archives, only dig through one post
>>> after the other... Do I miss something?)
>>>
>>> I want to bypass Amavis scanning for outgoing emails (I know there is
>>> some
>>> point to allow outgoing emails scanning, but this is another question
>>> IMHO), so I've done a few searchs and ended-up on that:
>>>
>>> http://marc.info/?l=amavis-user&m=113415019700881
>>>
>>> I tried to apply advise #2, i.e.: what follows the "Another way is more
>>> specific" sentence.
>>>
>>> So:
>>>
>>> - I added: "check_client_access hash:/etc/postfix/amavis_internal" to
>>> Postfix's main.cf
>>>
>>> - I wrote these two lines to: /etc/postfix/amavis_internal
>>> 10.10.10.11 FILTER amavis:[10.10.10.11]:10026
>>> 88.191.xxx.xxx FILTER amavis:[10.10.10.11]:10026
>>> (The email server is a linux-vserver, which is listening on 10.10.10.11,
>>> while amavis is running on another linux-vserver, with the 10.10.10.15
>>> IP
>>> address).
>>> Then I postmap'ed amavis_internal and reloaded Postfix.
>>>
>>> - Finally, I commented-out:
>>> $inet_socket_port = undef
>>>
>>> and added:
>>>
>>> $inet_socket_port = [10024, 10026];
>>> $interface_policy{'10026'} = 'INTERNAL';
>>> $policy_bank{'INTERNAL'} = {  # mail originating from the internal
>>> server
>>>   bypass_spam_checks_maps   => [1],  # don't spam-check outgoing mail
>>>   bypass_banned_checks_maps => [1],  # don't banned-check outgoing mail
>>>   final_spam_destiny   => D_PASS, # insure spam passes
>>>   final_banned_destiny => D_PASS, # insure banned files pass
>>> };
>>>
>>> in /etc/amavis/conf.d/50-user (this is a Debian vserver), then I
>>> restarted
>>> Amavis.
>>>
>>> Using this setup, emails are not delivered anymore. Here's what the logs
>>> say (vscan1 is the Amavis server, with the 10.10.10.15 IP address):
>>>
>>> mail.info.2.gz:Mar 12 03:16:30 vscan1 amavis[17484]: (!)Net::Server:
>>> 2011/03/12-03:16:30 Can't connect to TCP port 10024 on 10026 [Cannot as
>>> sign requested address]\n  at line 88 in file
>>> /usr/share/perl5/Net/Server/Proto/TCP.pm
>>>
>>> I dig the web a bit and believe that I found a post saying that amavisd
>>> can't listen on two different ports. I'm not sure as I can't find it
>>> anymore. Should I then consider that this kind of "mini-howto" is wrong?
>>> Do I miss something?
>>>
>>> Answers will be, of course, greatly appreciated :)
>>>
>>> Thanks,
>>>
>>> --
>>> Loic
>>>
>>
>> Amavisd-new can listen on more than one port. Here NET::Server is
>> trying to open the standard amavisd-new port 10024 on an IP address of
>> 10026? Something we are not seeing is misconfigured.
>
> Sorry for not posting my conf files... Indeed, you hit the point... Read
> below :)
>
>>
>> You might instead use the MYNETS example until it's sorted out. Maybe
>> you changed $inet_socket_bind by mistake.
>
> Definitely the right clue... SO THANKS A LOT GARY :) I'm ashamed, as I
> indeed changed $inet_socket_bind and not $inet_socket_port. Thanks a lot
> for guessing and replacing my blind eyes :o/
>
> So, all the conf is back to the state described above, with these slight
> changes:
> - $inet_socket_bind still equals to 'undef' #as this one should have been
> left untouched.
> - $inet_socket_port = [10024, 10026]; #as it should be from the start
> - originating => 1, #added to the whole '$policy_bank{'INTERNAL'}'
> statement. Thanks for the hint. Still I don't know what it does, could you
> light my lantern?
>
> I still have one big concern... Which is that all these rules don't seem
> to change anything (but at least both incoming and outgoing mail is
> correctly delivered :))
>
> e.g.: If I try to write to the address is use to post this mail from the
> server, I still get scores from Amavis, i.e.:
> Mar 28 00:42:17 vscan1 amavis[14705]: (14705-06) Passed CLEAN,
> [78.227.37.113] [78.227.37.113] <loic at xxx.xxx> -> <yanek at altern.org>
> Message-ID: <4D8FBD3E.3040609 at abetternet.net>, mail_id: 5AvS+S7--kuW,
> Hits: -2.9, size: 665, queued_as: 2AABB1A826B, 8170 ms
>
> So am I still missing something?
> Do you need my config files? (which ones?)

That could be because the  IP adress 78.227.37.113 is not listed in
/etc/postfix/amavis_internal

Is this address one of your network addresses, or is this a remote
client that is using SASL authentication? If using SASL, see a hint
here:
http://www200.pair.com/mecham/spam/bypassing.html#10

Probably need a better understanding of your setup.

You said: (The email server is a linux-vserver, which is listening on
10.10.10.11,
while amavis is running on another linux-vserver, with the 10.10.10.15 IP
address).

So are you using the amavis server as a gateway to the mail server (in
front of the mail server - acting as a relay server)? If so, may I
assume Postfix is running on it?
Which of the two servers are you configuring /etc/postfix/amavis_internal on?

Or is the email server Internet facing and you are using a secondary
server that is running amavis as the only MTA and you are passing mail
from the email server to the amavis server and back?

In other words, show your content_filter setting and tell us which of
the two machines it's configured on.

If I were to make the assumption that the amavis server is the
Internet facing server and it's acting as a gateway server (and your
internal email server is using the amavis machine as if it were a
relayhost (smarthost), in /etc/postfix/amavis_internal add only this
line and then test (after postmapping it):

10.10.10.11 FILTER amavis:[127.0.0.1]:10026

The next question would be, if using SASL auth, which of the two
servers are external clients connecting to? It would also have to be
explained what server it is your internal client machines are using
for their outgoing SMTP server.

It may be a simpler to configure MYNETS to start with for internal
clients, and then use the link mentioned above for SASL auth clients.

-- 
Gary V