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:<"email@example.com"@[OUR.IP.ADDRESS]>
<<< 250 2.1.5 Recipient address syntax Ok
<<< 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?
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 anything,
maskerading behind any mail address?
Thats what we have and i dont like to help bad users to do whath they are doing.
Thanks in advance.
> > The problem is that POP clients configure their from address to
> > firstname.lastname@example.org (for example) and send junk mail.
> > I want to limit a group of IP addresses to only be able to
> > use a specific group of domains in MAIL FROM
> The system does not have facilities to mandate source domains
> per IP addresses.
> We *could* try to create something of this type -- however
> the thing would be of type: "from this IP range, MAIL FROM must be
> of these suffixes" -- doing "this MAIL FROM is ok only from that IP-
> address range" would be separate issue.
> Doing it properly would require two new attributes, e.g.:
> - mailfromverify ".foo.fi:.faa.fi:fuu.fi"
> - mailfromip "[18.104.22.168]/24,[22.214.171.124]/25"
> We are running this type of policy things in separate applications
> when we have e.g. email-to-pager systems, which are built
> with "sender
> pays" rule.
> Running them at the major email relays is ... cumbersome.
> My workplace ISP operations are perhaps unusual, but we
> have some 24 000
> different email domains in use, of these 2700 are different
> in the top-most
> two domain components.. (compare with e.g. AOL approach,
> all have *same*
> domain.) We have also kwazillion dialup lines, and
> customers using our
> email services from their leased line connectivity.
> ... but if a decent model can be created to control the
> thing without
> too much revision of the code, then why not. I would not
> use it myself,
> but perhaps some other people could use it.
> > Thanks in advance, and special thanks for a grat piece of
> > Nicolás Baumgarten
> /Matti Aarnio <email@example.com>