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

Loic Condette yanek at altern.org
Tue Apr 19 02:06:05 CEST 2011


Sorry for answering that late, I was a bit sick these last days :(

> 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?

Indeed it is.

> If using SASL, see a hint
> here:
> http://www200.pair.com/mecham/spam/bypassing.html#10

Works perfectly and flawlessly, thanks a lot!

>
> 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?

No, read below.

> 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?

Yes, that's what I do.

>
> 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?

They connect to the mail server.

> It would also have to be
> explained what server it is your internal client machines are using
> for their outgoing SMTP server.

They connect to the same mail 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

Problem solved :)
Since every mail is submitted to the standard SMTP port (25), I used the
second hint described at:
http://www200.pair.com/mecha/spam/bypassing.html#10
(more precisely, what follows the "If for some reason SASL users connect
to port 25..." sentence.
Out of curiosity, I also run pop-before-stmp on this server, so that you
can still submit a mail as long as you successfully passed the POP/IMAP
authentication. So mails from such users can still be sent to tcp/25
without using SASL... I am wondering if there is also a way to bypass
amavis mail scanning for emails submitted this way?
(Just being curious... I'm not sure that I'll want to bypass amavis checks
for this kind of submission, so no hurry to answer :)).

Once again Gary, thanks a lot!

-- 
Loic



More information about the amavis-users mailing list