Re: [exim] Blocking Authenticated Exim user whose ip address…

normallybaffled wrote:
>
>
> You shoudl ordinarily expect that travelers, WiFi users, adsl, dsl,
> residantial
> dial-up WILL be on IP-blocks not intended for MTA use AND that fact alone
> doesn't mean they should be denied secure login if they are otherwse
> bona-fide
> members of your user community. (one DOES require secure UID:PWD match?)
>
> Quite the reverse - 'responsible' connectivity ISP may volunteer their
> dynamic
> pools to an RBL as it can help shut-down WinZombie routes to the outside.
> Hopefully they also intercept port 25 but NOT port 587.
> <snip>
>
> I hear you on responsible ISPs. Here is what I believe i have a problem
> with:
> When one of our users that "relays" mail thru one of our servers,
> (connecting from a blacklisted ip address -ie in senderbase.org as POOR )
> and the recipient is behind a Barracuda, we are finding that we (our mail
> server addresses) are being blacklisted by Barracuda Central. Then we get
> complaints from tons of users who can no longer send mail to anyone /any net
> using a Barracuda. We have separate servers for bulk mailing clients and no
> spam is allowed through our regular exim servers. We monitor our volumes and
> stats like mother hens. we have thousands of mail users -all of them
> legit-(we are strictly a corporate provider) so this is becoming quite an
> issue as we host mail services for companies worldwide- most have their own
> networks but some smaller accounts only have regular adsl with dynamic ip
> provision. thoughts?
> Bill

Versteh.

It is a bit off-the-wall, but similar to what can happen with even the
best-maintained of closed-post mailing lists - possibly with a similar
'solution' as well...

CAVEAT: it may break a few rules...

What you describe sounds as if overly-aggressive far-end filters (Barracuda or
otherwise) are boring down through *all* 'received' headers, AND NOT just the
DNS credentials and envelope-from of the 'last mile' connecting server.

IOW - they do not trust prior servers to have 'done the right thing'

IF that is the correct assessment, (and it may not be), THEN 'what worked for
us' - using Ecartis MLM as an example 'coz it is dead-easy - was to *archive*
100% of the incoming original, such that you have the pragmatic track-back
capability (and perhaps legally-required one) needed...

BUT then *strip all* prior headers, applying a 'fresh' set (only).

Exim can do this also, though it needs more than just the equivalent of a
box-tick Ecartis requires.

And - I did say 'CAVEAT' - it violates some very basic smtp principles...
some of which have *legal* standing in some jurisdictions.. with sharp teeth.

Did I say 'CAVEAT'?

But .. pragmaticaly - the paranoid far-end then 'sees' only your hopefully
squeaky-clean server, AND NOT the sometimes-dodgy route over which a legit
message had to travel to reach it.

Note that this need not deny access to those unfortunate enough to be on a
network OTHERWISE blackballed - so long as THEIR message is clean.

It goes without saying that adopting any part of such an approach requires one
to be more careful than ever that what they pass is NOT in any way nasty, ELSE
Lybarger's corrolary to Sod's Law applies [1] - and you might as well plan to
move domains and IP's every second day, if not keep a speedboat and extra
passport handy.

Me? Always happy to help the paranoid isolate themselves. Avoids potential
axe-wounds.

I'd just block the problematic destinations and advise those who bitched that
there was no valid mailserver running there. Deal with that by fax, phone,
dead-tree and postage stamp.

Or Gmail. Who may yet serve all of us up an 'early retirement'.

HTH,

Bill

[1] 'All else being equal, YOU LOSE'