Zitat von Randy Ramsdell <rramsd...@activedg.com>:
Victor Duchovni wrote:On Mon, Nov 29, 2010 at 03:01:45PM -0500, Randy Ramsdell wrote:So to rephrase, what would be the best practices way given I have to do forward this email and am powerless to change the design other than our setup which may only include trying to mitigate backskatter?If list expansion happens on your server, you can implement standard list management methods (an envelope sender address that is a list bounce-parser that uses VERP). If you are simply forwarding mail to an already expanded list, there is not much you can do. The list management problem is upstream, and needs to be handled there.We simply alias $user $u...@$othermailserverThe $users we forward to are known by our mail server and no mail will forward otherwise. I cannot think of a scenario which rejected mail from $othermailserver would be anything other than UCE in this case. The fringe issues would be a borked config which reject because of misconfiguration on their end which would result is lost mail if we drop all rejects from $othermailserver.What scenarios could occur which would make dropping these rejects a bad idea?
UCE or not will dedecided by the *remote* Exchange and if it fails (reject non spam) you are responsible in the first place because the mail was *directed* to your server. Therefore be prepared to proof the rejects so you don't get blamed for others faults.
Regards Andreas
smime.p7s
Description: S/MIME Cryptographic Signature
