On Tue, Jan 10, 2017 at 4:21 AM, Ferenc Kovacs <tyr...@gmail.com> wrote:
> I've spent some time yesterday and tonight with the ecelerity config, here
> are my results:
>
> On Tue, Jan 10, 2017 at 2:06 AM, Davey Shafik <da...@php.net> wrote:
>
>> Ferenc,
>>
>> As you can see below, the issue is even caused when the email has _zero_
>> URLs such as the one you replied to, which was also rejected.
>>
>
> yeah, unfortunatelly ecelerity is a bit of a black box, here is the
> relevant config:
>
> Validate validate/omniti_tools url_ripper {
> base="sbl-xbl.spamhaus.org"
> max_lookups = 100
> forward = true
> bits [
> 0.0.0.2 = "sbl_hits"
> 0.0.0.4 = "xbl_hits"
> ]
> address_headers = "Errors-To:From:Reply-To:Return-Path:Sender"
> }
>
> we don't know what does the url_ripper function do, exactly, my guess is
> that it fetches the links from the message body, and I also guess that the
> headers listed in address_headers will also searched for domains/ip
> addresses, and all of those will be matched against the
> sbl-xbl.spamhaus.org blacklists.
> the bit field controls what labels will be set for the given mail based on
> the response from sbl-xbl, and there are future rules later in the config
> which will trigger when those labels are set.
> as far as I can tell the following rull will be hit eventually which will
> stop the processing of the mail and fail the delivery:
>
> if not vctx :is "can_relay" "" {
> if not vctx :is ["connect-wl", "mailfrom-wl", "rcptto-wl", "user-wl"]
> "match" {
>
> # Other rules
>
> if anyof(
> vctx :contains "sbl_hits" "",
> vctx :contains "xbl_hits" ""
> # vctx :contains "sc_surbl_hits" "",
> # vctx :contains "ws_surbl_hits" "",
> # vctx :contains "ph_surbl_hits" "",
> # vctx :contains "ob_surbl_hits" "",
> # vctx :contains "ab_surbl_hits" "",
> # vctx :contains "jp_surbl_hits" ""
> ) {
>
> if vctx_conn :is "p_esmtp" "true" {
> ec_tarpit 40 "spam tarpit";
> }
> ec_action 550 text:
> 5.7.1 mail rejected by policy. SURBL hit
> Spammy URLs in your message
> See http://master.php.net/mail/why.php?why=SURBL
> .
> "spam:Spammy URLs in message";
> stop;
> }
> }
> }
>
> I was able to pinpoint that the sbl_hits label will be set for the false
> positives, and for now commented out this rule, but couldn't figure out
> what exactly triggers the sbl_hits label for these seemingly ok emails.
> (and of course our custom config is fairly comples, there are no available
> documentation anymore for ecelerity and it is a closed source product)
>
>
>>
>> Also, it was mentioned recently that we had moved away from ecelerity as
>> our MTA, but this indicates we are still using it for lists? If not, then
>> the change you made will likely not solve anything.
>>
>
> ecelerity is still used on the lists.php.net (pb1.php.net) box, it was
> only replaced for the php.net MX (which is now managed via a postfix
> install on php-smtp2.php.net) which was also running ecelerity in the past
>
>
this did not help (the sbl_hits was caught by another rule eventually), so
for now I've commented out the sbl_hits like from the validation block, so
basically disabled the primary spam filter until we figure out and fix the
problem properly.
--
Ferenc Kovács
@Tyr43l - http://tyrael.hu
