Robert McQueen schrieb:
Our mail system has many addresses which we accept and forward to our
users' addresses on other systems (ie, domain.com is a virtual alias
domain, and we forward [EMAIL PROTECTED] to [EMAIL PROTECTED], or whatever).
We use both reject_unverified_sender and reject_unverified_recipient to
check that the envelope from/to addressed are valid, so we never
generate the "obvious" backscatter where you're an naive MX that accepts
mail for a bogus addresses at the final destination, and then generate
bounces when the recipient turns out to be invalid.
However, we're now finding that more and more of our users' final mail
destinations are applying SMTP-time spam filtering, so actually reject
the message we're trying to forward due to it's contents. Because we've
already queued the mail, we then end up generating bogus bounce messages
to the original (obviously forged) senders.
We're now starting to get people reporting us to the likes of SpamCop
for originating backscatter, but in this case I really don't know how we
can avoid it. I've considered things like (in order of preference):
* forwarding the mail whilst the original sender is connected, and
returning any errors to them, so never spooling the mail
* never actually generating and sending bounce /mails/ except to local
users/destinations (who are using us as their smarthost), because we
never accept mail for invalid destinations in any other circumstances
* sending the bounces for the user's forwarders to the user's local
mailbox, rather than the original sender
Unfortunately I don't really know how to do any of them with postfix. I
did have a vague idea of doing some address re-writing, and then
pretending that the remote MX is a content_filter, but this absolutely
terrifies me. Does anyone have any better ideas?
Obviously we can look at deploying our own SMTP-time spam rejection with
content_filter, but that seems to a) pass the problem on to anyone who's
trying to forward mail to us, b) not solve the real issue which is that
we can never have /exactly/ the same definition spam as the systems
we're forwarding to.
Thanks,
Rob
Hi, traditional backup mx ( i think this is kind what you do ) is kindly
broken these spam days,
only do this if have all forwarding machines under your control
or/and have lists of all valid users and domains there
only this way you are able to bounce with unknown user at smtp income
time, and avoid spooling mails for unknown addresses and prevent mostly
backscatter.
Youre doing right just now for validate ( an hopefully cache )
the forward users on their servers via recipient verify , but this must
fail if they have
antispam mechanics ( i.e greylisting, spf etc ) which avoid quick validating
users mail adressess over smtp verify, so teach them to whitelist smtp
validating for your backup mx server ip, or tell them you will not
longer do it for them,
there is no other magic comming out of this problem using recipient
verify
Never validate all sender addresses, do this only in rare special
cases , cause more and more mailservers will treat you as spammer
by massive smtp conects !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
Use other smtp restriction to reject bots etc ( like
reject_unknown_reverse_client_hostname rbls etc ) but be aware that your
forwarding users may get mail traffic from ugly setuped mailhosts and
dont understand
your rejects, so this is kind of education, and rises the support rate
(so you have to find a good middle way for your restrictions )
But this all depend how you contracted and connected to them.
Its normal these days that backup mx have stronger rules then
endmailservers, but if your host is the only mx record for them
and your acting just to hide their mailserver , they have give
you a list of valid users and domains on their servers, or keep their
servers up for quick verify them.
As workaround you may install webmin and give them access by gui of
their user tables so they can edit them by themselves etc, or you
download it from them per cron , ldap what ever
Perhaps others on the list have more advanced ideas
--
Best Regards
MfG Robert Schetterer
Germany/Munich/Bavaria
