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 <[EMAIL PROTECTED]> 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 <
>>> [EMAIL PROTECTED]>: 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 <[EMAIL PROTECTED]>
>> 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 <[EMAIL PROTECTED]>
>> 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








-- 
## List details at http://lists.exim.org/mailman/listinfo/exim-users 
## Exim details at http://www.exim.org/
## Please use the Wiki with this list - http://wiki.exim.org/

Reply via email to