ietf-smtp
[Top] [All Lists]

Re: Recap Issues 0b/21/25

2007-05-01 00:20:19

At 20:12 30-04-2007, Frank Ellermann wrote:
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".

Then you understand the problem.

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

The MX is not always 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'm not thinking of "no MX" here. It may not always be possible to do recipient validation at "the border" you mentioned. But we can encourage people to do the policy filtering there and reject if they see fit. This in itself may decrease the number of bounces significantly.

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.

CBV is easily turned on in one well-known MTA and people will flip that switch if the RFC tells them to go and verify the sender's address. 4408 may be the lesser evil then. :-) RFC 4409 6.1 solves part of the problem. The major part of the problem lies at the receiver's end.

That wording doesn't consider that this determination can be also
as simple as one DNS lookup (or rather between 1 and 11 lookups).

It may be difficult to find a consensus for these DNS 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.

That may be history but we can always learn from it. Recently, a large email provider was sending all mail from a particular network into a blackhole. I doubt that we can call that "users being better served".

I read the last sentence you quoted as "better served by delivering any message that could be delivered subject to site policy". Sometimes it's better to err on the cautious side or else we end up with the site policy described above.

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.

Yes, the users would have been better served if the messages were rejected.

Regards,
-sm


<Prev in Thread] Current Thread [Next in Thread>