it is the responsibility of the MX machine to know what is and is not deliverable.
Again, this completely solves the issue of forged return address bounce e-mails.
Actually, no it doesn't.
Let's try another ISP-as-MX scenario, this time where the company runs its own mail server as primary MX, but uses the ISP's server as a secondary:
1. Spammer targets the backup MX (us), assuming it's less protected.
2. We queue, reject, or discard the message.
3. Mail ends up at customer's primary mail server, which rejects *on different criteria*.
4. Customer's server issues an SMTP reject to our server.
At this point, we technically *should* generate a bounce. The address we sent it on to was valid, but the message could not be delivered. We have no way of knowing, short of something SPF-like provided by the apparent sender's domain, whether the return address is valid, invalid, or valid-but-forged. On the other hand, if we *did* have that information, we could have blocked the mail without even queueing it up for the primary MX.
Now if you run all your MXes yourself, you can make sure they all use the same criteria and only reject mail at the border. But that's a bit more difficult when one is in-house and the other belongs to your ISP, who may not even be running the same mail server software as you, never mind the same filtering software.
And then there's the scenario in which the forged message makes it through to a valid address, someone reads it and fires off a complaint to the person they think sent it...
Kelson Vibber
SpeedGate Communications <www.speed.net>
_______________________________________________ Visit http://www.mimedefang.org and http://www.canit.ca MIMEDefang mailing list [EMAIL PROTECTED] http://lists.roaringpenguin.com/mailman/listinfo/mimedefang
