At 23:09 29-04-2007, Frank Ellermann wrote:
Whether those references are added or not, I still think the general
SMTP model has to be "tuned" for this millennium. All the "MUST NOT
reject" should be toned down (or removed if the problem they tried to
We should also consider the legacy systems out there. A complete
reversal to reject, no bounces, makes the model
unreliable. Currently, the sender assumes that the mail has been
delivered if they didn't get a bounce. If we push too strongly for a
"no bounce" approach, we'll be creating blackholes.
But there's only one place for the receiving side to decide this, at
the border MTA. Later is too late, it can cause bounces to innocent
bystanders, or - if the mail is dropped - it loses legit mail (in
the case of a "false positive").
Sometimes the "border" is not clear-cut, i.e. the mail may go through
several hops before reaching a MTA which can decide whether delivery
will be successful or not.
"[add REFERENCES here], has been done in providing ways to
ascertain that an address is valid or belongs to the person who
actually sent the message. A server MAY attempt to verify the return
path before using its address for delivery notifications, but"
as a push towards SPF and CBV. CBV looks like a way to get around
the fact that most mail serves have VRFY disabled. Under certain
circumstances, CBV can cause a denial of service.
I suggested a rewording of Section 6.2. as that section deals with
the bounces people have been complaining about. It favors rejects
without ruling out bounces.
Quoting two paragraphs from Section 6.2.
"delivered. Reliably determining that a return address is invalid can
be a difficult and time-consuming process, especially if the putative
sending system is not directly accessible or doesn't fully and
accurately support VRFY and, even if a "drop messages with invalid
return addresses" policy is adopted, it SHOULD be applied only when
there is near-certainty that the return addresses are, in fact,
"Conversely, if a message is rejected because it is found to contain
hostile content (a decision that is outside the scope of an SMTP
server as defined in this document), rejection ("bounce") messages
SHOULD NOT be sent unless the receiving site is confident that those
messages will be usefully delivered."
The wording above does bring the "SMTP model" in tune without making
email unreliable as it outlines the pros and the cons. The "SHOULD"
strikes the right balance while a "MUST" may be read as prohibitive.