Re: [exim] Help with relaying

Kezdőlap
Üzenet törlése
Válasz az üzenetre
Szerző: Giuliano Gavazzi
Dátum:  
Címzett: Patrik Jansson
CC: exim-users
Tárgy: Re: [exim] Help with relaying

On 21 Sep 2006, at 14:53, Patrik Jansson wrote:

>
>
>> On 19 Sep 2006, at 13:37, Patrik Jansson wrote:
>>> SenderHost    Sender Address    Recipient Address
>>> Local    *        *        no authentication
>>> *    local domain    *        authentication required
>>> *    not in local domain    local domain    deliver
>>> *    not in local domain    not in local domain    deny

>>>
>>> Please let me know if you think I have forgot something important.
>>>
>>>
>>

[...]
>> Since these rules have to be translated in some logical language
>> (exim configuration)
>> I think it is better to get rid of redundancy and put them in the
>> right order
>>
>> 1) is fine (some, like me, would require authentication even in this
>> case)
>>
> Yes, maybe that's better as long as customers don't need to
> authenticate when sending via scripts like perl or php. Will they
> still be able to do that?


well, I do not know about perl or php, but I suppose there is a
package to authenticate even in these languages. You have to balance
convenience with accountability, considering that authentication lets
you know who misused of the system if you receive complaints.

>
>> 3) better put it here (or you would require authentication for local
>> users sending to local users)
>> and should be rewritten:
>>
>> *    *    LOCAL DOMAIN    accept

>>
> Doesn't this make it possible with forgery? Someone could pretend
> that they are a local user by using a local domain in MAIL FROM and
> as long as they send to a local address the message would be
> accepted. The machines have like 500 e-mail accounts each on
> different domains/customers.


I cannot see what you mean here. You have to accept mail for the
local domain for existing local users. You can always forge the
sender address. Clearly you can add your antispam measures, but this
is not what you were talking about.

>
>
>> 2) moved after 3 and rewritten:
>>
>> *    LOCAL DOMAIN    *    accept if authenticated

>>
> Agreed.
>
>> 4) is actually not necessary as the default is to deny, but you can
>> add it (you might even want
>> to customise the message) in this form:
>>
>> *    *    *    deny

>>
>> as the is no point in checking source/sender/destination at this
>> point.
>>
>>> I think the following rules are interesting ( I have removed some
>>> comments
>>> ):
>>>
>>> begin acl
>>> check_recipient:
>>>
>>> accept hosts = :
>>> accept sender_domains = +whitelist_domains
>>>
>>
>> as the specs say:
>>
>> "Warning: It is a bad idea to use this condition on its own as a
>> control on relaying, because sender
>> addresses are easily, and commonly, forged."
>>
> Yes, I found that this rule was actually the one that troubled me.
> The domains in whitelist_domains are such domains that we, no-
> matter-what, accept incoming mails from as long as RCPT is local.


this is not what your rule was saying. If you check that the RCPT is
local then the rule is fine.
You could use:

accept  domains         = +local_domains
         senders         = @@partial-lsearch;whitelist_senders
         verify          = recipient


and in whitelist_senders you put:

# to whitelist a whole domain domain1:
domain1 *
# to whitelist specific users in a domain domain2:
domain2 user : user2 : user3 : etc

>
>
>>> accept hosts = +whitelist_hosts
>>> accept hosts = +whitelist_hosts_ip
>>>
>>
>> I would not whitelist any hosts unless you have full control over
>> them. Since authentication has to be used in some cases, it is better
>> to use it in most cases...
>>
> I'm not quite sure which hosts are added into these whitelists. I
> want to point out that this configuration is a default one when
> installing the control panel Direct Admin. But as you see, I'm not
> that pleased with it.
>


read the specs, start from the exim distribution default
configuration file and edit it.

>
>>
>>> accept senders = +whitelist_senders
>>>
>>
>> bad almost as much as the one above.
>>
> OK!
>


the rule I have given you above replaces those two bad rules and has
none of their drawbacks.


>> [... special local parts accept rule]
>>
>>> # accept if address is in a domain for which we relay as long as
>>> recipient
>>> # can be verified
>>>   accept  domains = +relay_domains
>>>           endpass
>>>           verify=recipient

>>>
>>>   accept  hosts = +relay_hosts
>>>   accept  hosts = +auth_relay_hosts
>>>           endpass
>>>           message = authentication required
>>>           authenticated = *
>>>   deny    message = relay not permitted

>>>
>>>
>>
>> as you can see you are missing the local accept rule (in which you
>> must also check the recipient).
>>
> And how would that rule look like? I'm not that good at exim
> configuration...yet! I have ordered Philip's official guide but it
> hasn't arrived yet.
>


this is taken directly from the spec file in the exim distribution:

accept domains = +local_domains
        endpass
        verify = recipient



> I will give you the particular problem in more detail. Sometimes we
> get mail from people who complains that they cannot send mail to
> customers on our servers because they're blocked, by SORBS or CBL
> or whatever. We state that they have to talk to the administrator
> of their mail server to check why they're in those lists but we
> most often also add their domain in whitelist_domains so that they
> can continue with their mail conversation with customers on our
> server. As you understand we don't want unhappy customers, and
> customers who can't communicate with their friends / partners
> aren't happy. And in many cases they don't give a da** if the
> problem doesn't rely on OUR servers. Therefor the use of
> whitelist_domains.
> Do you think this is a bad idea?
> Well, we only want the whitelist_domains to affect mails which
> should be delivered locally but that isn't how the configuration is
> set up to work today.


then the rule I gave you above can be used in your case. But remember
that if the sender is on a reputable, or even more than one, black
list, you have a good point in not accepting their e-mails. You can
tell your customers that if you start making exceptions the spam load
will eventually increase. But remember that if you don't fix promptly
your configuration it is your server which is going to go on some
blacklist, and with good reasons.

Giuliano