Re: [exim] Extrange behavior with smarthost and routers

Αρχική Σελίδα
Delete this message
Reply to this message
Συντάκτης: W B Hacker
Ημερομηνία:  
Προς: exim users
Αντικείμενο: Re: [exim] Extrange behavior with smarthost and routers
Jonathan GF wrote:
> This seems to be. In both smarthost and server i have this lines:
>
> [... other checks ...]
> accept  hosts        = +relay_from_hosts
> require verify          = sender/callout=15s,defer_ok/no_details
> accept  authenticated   = *
>             encrypted       = *
> [... other checks ...]

>
> Graeme says the correct should be accept the "<>" in the smarthost, but i
> don't know how to modify the "require verify sender" directive. Should i add
> something like
>
> require verify = sender/calloutt=15s,defer_ok/no_details
> accept domains = +local_domains
> endpass
>
> Thanks in advance.
> Cheers,
>
> Jonathan GF
>
>
>
> On Feb 4, 2008 10:15 PM, W B Hacker <wbh@???> wrote:
>
>> Jonathan GF wrote:
>>> Hi Dave,
>>>
>>> first of all i have to say that...yes.. i was? obfuscated. I tried to
>> post
>>> as much information as posible and i only casused noise. You got reason.
>>>
>>> What i tried to state in the previous mail is that, even if the
>> smarthost
>>> works, and the server behind works also, the bold lines shows an anormal
>>> activity.
>>>
>>> The logs, without the bold lines represent a normal behavior:
>>>
>>> Gmail -> smarthost -> server    (and vice-versa)

>>>
>>> But the bold lines show something like this:
>>>
>>> Gmail -> smarthost -> server -> call back to the smarthost     (let see
>> the
>>> lines again)

>>>
>>> 2008-02-04 01:05:48 H=mail.surestorm.com [89.128.3.108] F=<> rejected
>> RCPT <
>>> jonathangf@???>: Relay Not Permitted
>>> 2008-02-04 01:05:48 unexpected disconnection while reading SMTP command
>> from
>>> mail.surestorm.com [89.128.3.108]
>>>
>>> This lines appears in the smarthost log, so it tell me the server, after
>> put
>>> the message in the correct inbox tried something else. This sounds to me
>>> lika a loop.....What do you think?
>>>
>>> Cheers,
>>>
>>> Jonathan GF
>>>
>>>
>>>
>>> On Feb 4, 2008 9:47 PM, Dave Evans <exim-users-20071221@???>
>> wrote:
>>>> Firstly, please carefully read http://wiki.exim.org/DontObfuscate ,
>>>> including
>>>> the "Why was I sent this URL?" section.
>>>>
>>>> On Mon, Feb 04, 2008 at 09:29:58PM +0100, Jonathan GF wrote:
>>>>> Unless the architecture work i can see weird messages in the logs,
>>>> something
>>>>> i want to fix because they sound like a loop between the exim
>> smarthost
>>>> and
>>>>> exim mail server.
>>>> Doesn't look like that to me. To me, it looks like the smarthost
>> receives
>>>> the
>>>> message <a50c1e90802031605p2bf68fd1l26e54a85b7216a0e@???>
>> from
>>>> 66.249.82.231; it sends the message to 89.128.3.108 using the
>>>> send_to_mailserver router. The mail server then receives the message
>>>> (from
>>>> 64.79.209.162), and sends it to a maildir (virtual_user router).
>>>>
>>>> Is that not what's meant to be happening? If not, please try
>> explaining
>>>> again
>>>> what the problem is (and take heed of the advice on DontObfuscate).
>>>> Thanks!
>>>>
>>>> --
>>>> Dave Evans
>>>> http://djce.org.uk/
>>>> http://djce.org.uk/pgpkey
>>>>
>> Check also if you are asking one Exim instance to attempt a sender
>> verify, but not configuring its sibling to be aware of what consitutes a
>> valid sender - i.e. one it 'knows about' and respond accordingly.
>>
>> Bill
>>
>>
>


Just my preference - but I'd start by commenting it out altogether while
you do a more specific review of how you want it to work within the
larger scope of the 'rest of' your Exim environment.

Again 'personal preference', but I find it less troublesome to respond
to not-user-specific sender verification requests made from others,
(effectively saying, 'Yes, we are the responsible MX for that
<domain>.<tld>) as it is not all all predictable which others may make
such requests - then rely on other means to 'vet' the soures of
incoming traffic - again, as it is impractical to know who will support
your query TO them, and who may not.

Some Sysadmins are even on record as considering receipt of such a query
as grounds to blacklist those making them. No doubt a few even do so.

But within your own 'pool' - just two servers in this case:

- a server-but-not-account specific sender verification callout should
not be needed. You know exacty which two servers are involved, and can
vet each to the other without callout.

- an account-specific sender query could be useful if one of the servers
needs, but does not have, acess to a copy of the file/db of permitted
users - substituting for the need to export/share such a list and keep
it synced.

But if you are not using, and do not need, that level of detail, there
is no need to go there, either.

IOW - depending on the *rest* of your tests, you may be able to do
without sender verify just fine.

HTH,

Bill