Chris Haynes wrote:
I am coming out of delurk for a moment. But could someone please
explain why we are having this discussion? I mean, rejecting with a
5.x SMTP error code, based on whatever criteria, creates neither
less, nor more liability, than doing so, also for whatever reasons,
has done for the last few decades. There is, from the perspective of
the sender at SMTP level, nothing fundamentally different between,
say, being rejected based on an entry in the access database, and
being rejected based on something found, or not found, in the
headers.
In accordance with the process defined by the Chairs I am explaining
_my_ inability to deploy Sender-ID.
And I respect your objections. I just have a series of my own. :)
You then proceed to cause a bounce to be sent to a recipient defined
in a message you _know_ to have been repudiated.
But I do *not* cause a message to be sent. I reject a connection. As Jim
astutely pointed out, if others see fit to take my rejection and create some
sort of bounce, what is it to me? I am certainly not the one having sent any
message; nor the one having *caused* to be sent anything. Like I said, all I
do is reject a connection.
"Why", the courts may well ask, "did you send a message, known to you
to be forged and potentially carrying malicious content, to this
innocent child?"
"But, Your Honor, I did *not* send a message. To up You even one, I caused
the immediate and unconditional abortion of the transmission of said
message, the moment I became aware of it being a forgery. Would Your Honor
rather have I had accepted the message, only to find myself in Your
illustrious Court, next month, for having aided and abetted in the
transmission of said forgery, whilst I had been made aware of its fraudulent
nature? Surely not!"
When a domain owner publishes a "-all" SPF-record, and a connecting host
falls within that category, then the domain owner is effectively instructing
me as follows: "I have not authorized IP address such-and-such to send mail
on behalf of me; please, treat the message as a forgery, and reject the
connection." Have you thought about the legal ramifications of ignoring that
instruction? If the entity in question is a large financial institution, for
instance, and I had been explicitely told, via DNS, that a message in their
name was a forgery, then I believe my safest legal bet consists of honoring
the domain holder's request to reject the message; or rather, not to deliver
it. Which leaves me DISCARD.
There *is* a technical reason against discarding a message, however. Quite
simply, it makes SUBMITTER useless. Because when you DISCARD a message, you
have to wait out the entire transmission, past the DATA phase, only to
pretend you accepted it, while discarding it silently.
See, the problem, IMHO, is not me *causing* a bounce to be generated on the
connecting host, but the connecting host sending me the forgery! Had the
connecting host checked for forgeries, he would A) not have sent me the
message to begin with; and B) not have bounced to a (possibly) innocent
third party upon my rejection. All of which, really, has nothing to do with
me. I just take *my* responsibility in rejecting the forgery.
YMMV; and, obviously, it does. :)
- Mark
System Administrator Asarian-host.org
---
"If you were supposed to understand it,
we wouldn't call it code." - FedEx