Re: [exim] require_verify = sender + RBLs - clarification on…

Top Page
Delete this message
Reply to this message
Author: W B Hacker
Date:  
To: exim users
Subject: Re: [exim] require_verify = sender + RBLs - clarification on the How-to
Chad Leigh -- Shire.Net LLC wrote:

> On Oct 21, 2006, at 7:44 AM, Alon wrote:
>
>
>>Third, You made the point/case that:
>>
>>"Some very large / major ISP's do not have usable DNS records for
>>their
>>'pools' of servers."
>>
>>NOW that's something to be concerned about. Since I'm running a shared
>>hosting environment with folks from
>>all over the world, it is very likely that some of them are
>>interacting with
>>servers that are indeed poorly maintained/configured.
>>That is a valid reason by itself why NOT to use this feature.
>>I can lecture to my clients that they SHOULD instruct their buddies
>>out
>>there to lecture their service providers... and yeah..going
>>back to reality this is never going to happen.


A finite, but very large number of .com and .net domains are 'parked' with
Network Solutions. For a very reasonable fee, NetSol also provide email service
for those domains. Thousands of individuals, hundreds, if not thousands of SME,
and a few larger businesses who have not gotten a round tuit w/r migrating to
ther server use this service.

Some months ago this was found to be problematic for our clients.

We start with host -v, dig, and whois to discover separate inbound pools.

We ended with digging thru the reject log to find 'stealth' servers used for
*outbound* that:

- had imprpper or NO DNS entry,
- improper or missing PTR,
- HELO mismatched, and to the point where a HELO might return a different
verdammt *.tld*, (.net and .com mixed) as well as different domain, not to
mention the mismatched prefixes used.

We had to 'VIP-list' that mess, as a simple whitelist was not good enough.

They broke everything that could be broken but TCP/IP itself.

:-(

>
>
> I have verify sender with callout and we have customers all over the
> world. We have had very little mail loss that is verifiable and when
> we do, almost 100% of the time we were able to get the offending
> server to "fix" itself to become conformant the RFCs regarding DSN
> and <> (every one that has failed for us has been someone who rejects
> <> sender as spam). We are a small provider and are not the best
> example due to how small we are compared to big mail providers but it
> has not been a real issue with us that it has disrupted mail service
> or caused problems. A handful of times we have pointed out to the
> offending senders that their servers are misconfigured (we always
> take the angle that we cannot accept mail from people who do not
> accept an appropriately sent DSN) and most of the time they have
> fixed their problem. We did have to whitelist one person whose
> provider is generally clueless about almost everything and one
> provider wouldn't even talk to us as we were not his customer... Our
> users/customers have greatly appreciated the service as well. We are
> always trying to improve our spam checks so as to not have to do a
> callout but the callout does greatly reduce the amount of spam we
> have to accept and deliver.
>
> Chad
>


NetSol doesn't care about RFC's or DNS correctness or smtp manners.

They don't *have to*.

(more's the pity, but what's a Mother to do?)

Bill