On Tue, 2004-08-24 at 11:54, Jim Lyon wrote:
A reasonable use of SenderID is to use it at SMTP time, and to refuse to
accept forged mail.
A reasonable use of SMTP may be for relaying mail without completing all
checks at each MTA, such as ensuring recipients within the local domain
are all valid. Even if Sender-ID were checked by each MTA, it would be
unreasonable to expect spam would be refused as a result. Although
there may be a learning curve, don't expect finding "open" records to
prove an insurmountable discovery.
If you refuse to accept it (by giving an error at end of DATA), you
won't generate a bounce.
If the MTA is a relay receiving the refusal, then this MTA _MUST_
generate a bounce.
The MTA that was sending the mail might or might not generate a
bounce, but that's his problem, not yours.
If the bounce is to you, from an MTA regarded as a reputable, you
receive these bounces. If this mail stream is within an
administratively shared realm, then the problem may occur at your
provider's relay. Either way, Sender-ID does not curtail this problem.
In fact, most of the forged mail is sent by specialized spam engines or
virus propagation engines. These engines won't generate bounces,
they'll just give up and go on to the next victim.
These specialized spam engines are not likely to be rejected either.
Sender-ID makes it _extremely_ easy to spoof MTA permissions!
So, deploying SenderID should result in fewer bounces, not more.
Sender-ID pays no attention to the return-path. How do you arrive at
there being fewer bounces? Those that attempt to ratchet up their
acceptance levels for Sender-ID will actually invite more of this
spoofed return-path behavior, as Sender-ID is unable to discern when the
return-path is valid.
-Doug