W B Hacker wrote:
> Seth Dillingham wrote:
>> On Thu, Apr 28, 2011 at 2:24 PM, Dave
>> Evans<exim-users-20081202@???
>>> wrote:
>>
>>> Please read http://wiki.exim.org/DontObfuscate then re-post with more
>>> details
>>> - I suspect that the key information is in your logs, but you've
>>> edited it
>>> away when posting, which makes it hard for us to help you.
>>>
>>
>> Here's the same as my first try, but de-obfuscated. My apologies!
>>
>> I'm running exim 4.72 to service a small number of users (less than
>> 50) and
>> to relay mail from a few groupware apps running on one particular
>> machine (
>> samson.free-conversant.com).
>>
>> Samson sends email 'from' quite a few different addresses. It can have
>> any
>> number of group projects, and each group project has a name, and the
>> names
>> become part of a cluster of associated email accounts, such as "
>> project1-site@???" and "project1-calendar@???" and "
>> project1-subscribe@???".
>>
>> I have samson's FQDN, ip address, and the verizon-generated FQDN for the
>> public ip address (see below) all added to my relay-from-hosts file,
>> which
>> then looks something like this:
>
> Cutting to the chase:
>
> sampson *cannot* respond in the manner Exim expects so see from a
> 'sender verify'.
>
> A) sampson MAY not even be reachable *at all* on the callback.
> You did say Verizon...
>
> ;-)
UPDATE:
Below, AR: 'sampson'
IATR: 'officeinsight' (than cannot respond to sender_verify)
AND
I appears to be OTHER THAN 'in-house' where you aren't receiving
sender_verify responses (as in primages@???).
mea culpa.
Let's clarify:
You should NOT expect a predictable and useful response to a
sender_verify from any entity with whom you do not have in-place a prior
agreement to provide such.
Many if not most will simply ignore you. Some few may blacklist you.
tua culpa
It may not *matter* until you ALSO get a proper PTR RR in place from
Verizon:
# host 74.103.212.3
3.212.103.74.in-addr.arpa domain name pointer
static-74-103-212-3.prvdri.fios.verizon.net.
'static' is a nicer word than 'adsl' or such, but that is still a
'generic', artificially-generated PTR RR. Primary use is Verizon's
debugging.
What you want will say:
free-conversant.com
or
mail.free-conversant.com
Fix that soonest if you want trouble-free acceptance world-wide.
I block on it. No one cares.
But MOST of the top global ISP's ALSO want to see a valid PTR RR that
matches to the sending MX FDQN (HELO is usually a don't-care).
Honor THEIR needs. Unless you plan to become a hermit.
>
> B) sampson (probably) isn't even a full-fledged MTA, so cannot respond
> even to a non-specifc sender-verify.
>
> C) even sampson is both an MTA AND reachable, it almost certainly
> doesn't have *specific* 'accounts' that could claimn receive mail to the
> <generated> addresses that must be an exact match to the more
> user-specific 'sender' Exim can attempt to verify. That can be faked -
> bots do it all the time. But ask yourself how useful the ender-verify is
> then?
>
> sender-verify's best use IS between/among members of a collaborative
> mob, wherein all hands have agreed to respond appropriately AND NOT
> blacklist each other for it as abuse. Your situation fits that at first
> glance.
>
> But a key-player - 'sampson' - is UNABLE to play by the expected rules.
> And - you probably already have 'good enough' source control loking at
> the source IP.
>
> CAVEAT: Any web-app warrants close watching and beefed up filtering.
> ClamAV for sure. SA maybe. Ratelimit if need be.
>
> Meanwhile:
>
> Either exempt sampson from sender verify attempts, OR 'fix' sampson so
> it CAN respond as expected.
>
> Test and confirm first by turning sender-verify OFF altogether, as that
> is fastest and simplest.
>
> It may not be your only barrier, so keep an eye out for what else pops up.
>
> Then go back with longer-term fix(es).
>
> HTH,
>
> Bill Hacker
>
>
>
>
>>
>> 74.103.212.3
>> static-74-103-212-3.prvdri.fios.verizon.net
>> samson.free-conversant.com
>>
>> The problem I'm having is that mail from samson is being rejected with
>> verification errors. I thought I had exim configured to relay from samson
>> correctly, but I've obviously done something wrong.
>>
>> I'm a n00b. Not going to pretend I know what's wrong. Here's an example
>> rejection, from my mainlog:
>>
>> 2011-04-25 11:55:27 H=static-74-103-212-3.prvdri.fios.verizon.net (
>> samson.free-conversant.com) [74.103.212.3] sender verify fail for<
>> officesite.officeinsight-confirm@???>: Unknown user
>>
>> 2011-04-25 11:55:27 H=static-74-103-212-3.prvdri.fios.verizon.net (
>> samson.free-conversant.com) [74.103.212.3] F=<
>> officesite.officeinsight-confirm@???> rejected RCPT<
>> primages@???>: Sender verify failed
>>
>> My exim.cf has this:
>>
>> Under the Main Configuration Settings:
>>
>> hostlist relay_from_hosts = lsearch;/etc/exim/relay-from-hosts
>>
>>
>> my acl_check_rcpt contains (among lots of other things):
>>
>> acl_check_rcpt:
>>
>> accept hosts = :
>> control = dkim_disable_verify
>>
>> deny message = Restricted characters in address
>> domains = +local_domains
>> local_parts = ^[.] : ^.*[@%!/|]
>>
>> deny message = Restricted characters in address
>> domains = !+local_domains
>> local_parts = ^[./|] : ^.*[@%!] : ^.*/\\.\\./
>>
>> deny condition = ${if eq {$sender_address_local_part}{postmaster} \
>> {true}{false}}
>> sender_domains = +local_domains
>>
>> deny condition = ${if eq {$sender_address_local_part}{nobody} \
>> {true}{false}}
>> sender_domains = +local_domains
>>
>> accept local_parts = postmaster
>> domains = +local_domains
>>
>> require verify = sender
>>
>> accept hosts = +relay_from_hosts
>> control = submission
>> control = dkim_disable_verify
>>
>> accept authenticated = *
>> control = submission/sender_retain
>> control = dkim_disable_verify
>> add_header = X-Authenticated-Sender: ${sender_address}
>>
>> require message = relay not permitted
>> domains = +local_domains : +relay_to_domains
>>
>> require verify = recipient
>>
>> accept
>>
>> (Sorry if this is hard to follow.)
>>
>> Can anyone help me figure this out?
>>
>> Seth
>
>
