"Jim Lyon" opined:
You're between a rock and a hard place. If you simultaneously believe
that all of the following are sinful:
1. To accept and deliver forged mail.
2. To accept forged mail and silently discard it.
3. To accept forged mail and then generate a bounce.
4. To reject forged mail because the sender might generate a bounce.
then you have no alternatives left.
Actually I was advocating (2) - but only in the special case when the Mail-From
entity has declined responsibility for the message by causing a test 'fail'.
We need to have SPF_Classic+SRS or an equivalent 'on the table' so that the
experts can explain to you why a (2) can be justified following a Mail-From
test, but not following a PRA test.
The current drafts give you a way to avoid (1) -- that's their whole
point. They leave it as a local policy decision as to which of 2, 3 or
4 you choose. They recommend (4) with a "SHOULD", but you can
reasonably do either of the others.
Today, many large ISPs silently discard mail that they classify as spam.
I expect that those ISPs will choose (2) when implementing SenderID.
Woah! Home on there! There's a new, really serious point here.
You claim in (2) that the drafts give authority for MTAs to silently discard
messages. I cannot find that authority in the drafts.
There is an absolutely critical, overriding requirement imposed on all
components of SMTP systems by RFC2821.
I quote from section 2.1
".. message transfer can occur in a single connection
between the original SMTP-sender and the final SMTP-recipient, or can
occur in a series of hops through intermediary systems. In either
case, a formal handoff of responsibility for the message occurs: the
protocol requires that a server accept responsibility for either
delivering a message or properly reporting the failure to do so."
This is fundamental to SMTPs' ability to provide a reliable service.
Now -core-03.txt, section 5.3 says that on failure a server 'SHOULD reject the
message' using a 550 method. That conforms to RFC2821. But what alternative
actions are available?
I had assumed that the alternative, should the advice not be heeded, would be to
continue to process the message in some way - still in conformity with the
RFC2821 requirement to 'deliver or report'.
I hope you are wrong in your assertion in (2) that the -core draft authorises
the silent discarding of messages.
If the drafts do conform to RFC2821, then the technical assertions backing this
entire thread, and justifying my inability to deploy Sender-ID remain
If these drafts do permit the silent discard of messages on the basis of a PRA
test failure as a 'local policy decision', as you suggest, that would be grounds
for a significant TECH-ERROR submission: Sender-ID would be breaking the general
requirement imposed by RFC2821.
Where do the drafts authorise or advocate the silent discarding of messages?
Your thoughts about MAIL-FROM, HELO and EHLO don't change the above
calculus at all. They merely change the details of which messages you
classify as forged.
No. not 'merely'.
The repudiation of a message by its envelope sender (Mail-From entity) has an
entirely different significance in the context of RFC2821 than repudiation of
its content by a PRA test.
We need SPF_Classic+SRS, or an equivalent, on the table for this sub-debate to
-- Jim Lyon