ietf-smtp
[Top] [All Lists]

Re: Recap Issues 0b/21/25

2007-04-30 20:35:28

SM wrote:

We should also consider the legacy systems out there. A complete
reversal to reject, no bounces, makes the model unreliable.

+1  We're not going to copy the SpamCop FAQ wholesale into 2821bis.
( Nevertheless I've invited the SpamCop newsgroup readers to chime
  in, some have rather radical ideas compared with what we say. :-)

If we push too strongly for a "no bounce" approach, we'll be
creating blackholes.

Yes, there's a similar situation in NetNews, if you go too far in
attempts to avoid "dupes" (articles arriving more than once) you
get "nopes" (articles arriving less than once), and for obvious
reasons I always considered "nopes" as worse than "dupes".

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.

The border is defined by query=mx, and among the mailers acting
as MX the first getting mail from another mailer is "the border".

That's what I think how "border" could be defined, ignoring some
corner cases like "no MX" or all definitions of "local mail" if
it touches an MX.

I read:
    "[add REFERENCES here]
[...]
as a push towards SPF and CBV.

I think CBV isn't specified in any RFC, and so we can't add a
reference to it.  Similarly there's no RFC for grey-listing,
SRS, SES, CSV, or BATV.  Referencing RFC 4409 chapter 6.1 should
be okay.  For 4408 I'm not "neutral" (4409-1=4408 is nice :-)
Maybe one example 4409 6.1 is enough.

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,
 invalid."

That wording doesn't consider that this determination can be also
as simple as one DNS lookup (or rather between 1 and 11 lookups).
I'm not yet happy with the statement before your quote:

   address, although the history of the network is that users are
   typically better served by delivering any message that can be
   delivered.  Reliably determining that a return address is invalid can

This IS history.  It should say "the history of the network was
that users were typically better served by delivering any message
that could be delivered."  Past tense.

While I wrote that I've started my REXX excuse for procmail, and
it will now delete the next about 950 of 1200 pending mails that
arrived in the last hour.  Today users are typically better served
by rejecting suspicious messages at the border, otherwise they end
up in obscure blackholes.

Frank