In your example, it wasn't clear to me whether or not the
the small business domain published a Sender ID policy
in the DNS.
Assuming the domain did not publish any policy data, the
receiving MTA cannot perform the Sender ID test if there
is no policy information in the DNS, so the message should
not be rejected with a 550 error unless it has is some other
good reason to do so.
On the other hand, if the domain did publish a Sender ID
policy and the message is rejected for policy reasons, then
either the policy data is inaccurate or the ISP is doing
something to the message that it shouldn't be doing.
So, I still don't understand the crux of your complaint
about Sender ID here. How is Sender ID causing any harm
to anyone here?
Redwood City, California
Small business: (Virus on) End user MUA sends message to internal MTA,
stores-and-forwards message to public-facing MTA of the business' ISP.
This ISP-MTA has not implemented Sender-ID, so does no know that the PRA
later be detected as a forgery. This ISP is generally slack about security,
adding Resent-From headers, etc.
ISP-MTA accepts message for onward delivery, cannot initially contact
destination MTA, stores message and undertakes to try again later.
Second attempt to contact destination MTA succeeds.
Destination MTA applies Sender-ID, rejects message during SMTP protocol
with a '550'.
ISP-MTA notes the '550' and fulfils its 'contract' by generating a
"Bounce" message, which is sent to the address in "Mail-From" in the