[Raw Msg Headers][Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Policies and RELAYCUSTOMER
On Thu, Jun 08, 2000 at 10:55:15AM -0300, Nicolas Baumgarten wrote:
> Thanks fo the fast answer...
> After a combination of events we finally get to RBL.
> One of our users, hiding behind a yahoo account sent a big spam,
> somebody do the right thing, submitted us to RBL an we are blocked:
> This is the RBL report
> <<< 220 relay2 ZMailer Server 2.99.51 #1 ESMTP+IDENT ready at Tue, 6 Jun
> 2000 12:33:42 +0300
> >>> MAIL FROM:<spamtest@[OUR.IP.ADDRESS]>
> <<< 250 Ok (verified) Ok
> >>> RCPT TO:<"firstname.lastname@example.org"@[OUR.IP.ADDRESS]>
> <<< 250 2.1.5 Recipient address syntax Ok
> >>> DATA
> <<< 354 Start mail input; end with <CRLF>.<CRLF>
> >>> (message body)
> <<< 250 2.6.0 S33888AbQFFJeE message accepted
> /var/local/maps/rss/bin/rly: relay accepted - final response code 250
> Is this fixed in future versions?
> Any quick fix for this to get out from RBL?
As long as smtpserver runs without interactive router, there
is no guaranteed way of knowing, which recipient address is
valid local one, which is bogus. ZMailer receives anything
looking to be local, and then latter sends back a reject.
Adding letters 'f' and 't' to the '*'-tag at the end of the
usual smtpserver.conf file will get the router to process
incoming addresses interactively, and then report if particular
recipient really exists -- or not. (No, it isn't guaranteed
thing even then in all cases, unfortunately.)
It may be that the router, or its scripts mishandled that
local-part processing, and got it dequoted at wrong phase.
(If the message got sent out to <email@example.com>, and
not a bounce to <spamtest@[OUR.IP.ADDRESS]>)
This is a false-positive which RBL test script reports, not
a real thing.
> And going back to the makerading thing..
> There is something i'm missing?
> If, as you (Matti) said have "kwazillion dialup lines" that mean
> that those IP addresses should have full_rights and anybody can send
> maskerading behind any mail address?
> Thats what we have and i dont like to help bad users to do whath they are
The problem is that to *know* what some address user is allowed
to claim at any given moment is not an easy thing.
Some mechanism alike whoson might help by logging dialup login
into itself, and then some additional databases could be queried
to know all addresses that that particular user is allowed to
use -- only then this type of blocking is sensible.
(Remember: Dialup lines use dynamic address pools, same user will
likely appear with different addresses every call, and same address
will be reused by different users..)
After recent "Doctor is on the net" SPAMs, I got enough steam
to complete my old content-policy hooks, those could be used
also to write this type of analyzer you are looking for.
> Thanks in advance.
/Matti Aarnio <firstname.lastname@example.org>