Quoting Blu ([EMAIL PROTECTED]): > Are you suggesting then, that we should not relay mail at all?, not even > to/from our customers?
I'm quite non-plussed at this question, since it seems to suggest that you weren't following the thread. Earlier, I mentioned (to summarise and review) that I take care to have my MTA reject mail it considers inherently objectionable on various grounds, as a superior alternative to performing such processing after acceptance. (Among other things, it allows my system to say "no" without being guilty of generating bogus bounces to forged addresses.) Mr. Stone then opined that he saw no advantage because an upstream MTA might (e.g., if it was a relay) react to my 55X Reject by issuing a bogus bounce of its own. I've heard this sort of comment before from people who really ought to know better, and who actually _do_ understand the concept of local responsibility. Maybe they're bored and are trolling; it's difficult to say. Or maybe they're just following the ever-popular philosophy of post first, think later. To spell it out, I'm responsible for making sure _my_ MTA isn't misbehaving. I'm not responsible for _your_ MTA misbehaving. If some upstream MTA (such as, hypothetically, yours) decides to take do something irresponsible and socially destructive (such as sending spam to a forged alleged sender) in reaction to my MTA saying "No, I don't accept that mail", then that _other_ MTA's admin is accountable for _his_ system's misbehaviour, and I hope and expect that we will all (figuratively) LART him until he bleeds. Now, if that MTA's admin says "Hey, I'm not responsible; I'm just a poor innocent relay", I'd say he'd better get accustomed to being accountable for mail his system sends out, since other admins _are_ clear on that point, even if he isn't. If the admin has no other way of making sure his system doesn't incontinently issue bogus "bounce" messages to forged addresses when spam/malware is refused downstream, then he'd be well advised to improve his _own_ ability to reject bogus mail, making its subsequent relaying a non-issue. Please also (since you're a relay) read the prior posted links about SRS. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
