One of our mail baggers got blacklisted by orbs for relaying % hack
domains, despite having it turned off. You didn't include enough
information to tell if this is what happened to you, but I'll share the
story anyway.
ok, we had domain isp.com. MX records looked like this:
@ IN MX 0 primary.isp.com.
IN MX 5 secondary.isp.com.
IN MX 10 tertiary.isp.com.
secondary and tertiary are running exim (3.32 at the time) w/ percent hack
turned off. primary was (not anymore, thankfully) running smail. smail
was configured to do percent hack relaying, but only if you were allowed
to use it for relaying anyway. That is, you were only allowed to send to
user%remote.com@??? if you could already send use the server to send
to user@???. Basically this was open to our customers, or, more
literally, anyone using an IP address from our /18.
This worked for 5 years w/ all the servers running smail because all smail
installations saw this as a remote domain and rejected it up front (or
accepted if it was from our IP block.
When we put exim on secondary and tertiary, this broke. exim on secondary
saw user%remote.com@??? purely as an address to be bagged for, with
the bizarre username of user%remote.com, and accepted it from the sender
no matter who the sender was. Then, secondary handed it to primary, and
this is where it broke. primary _did_ recognize it as a percent hack
domain, _and_ secondary was allowed to relay to remote recips, so the mail
got delivered to user@???. I guess the point is, even when all the
pieces are working as expected, they may not interact the way you think
they will.
I solved all this by putting a router in place that rejects any email w/ a
% or a ! in the username (turns out after I fixed the % problem, smail
also had a problem w/ !, presumably because of it's uucp handling role).
</long explanation>
--John
