Rich Kulawiec <[email protected]> writes:
> On Fri, Feb 19, 2010 at 08:20:36PM -0500, William Herrin wrote:
>> Whine all you want about backscatter but until you propose a
>> comprehensive solution that's still reasonably compatible with RFC
>> 2821's section 3.7 you're just talking trash.
>
> We're well past that. Every minimally-competent postmaster on this
> planet knows that clause became operationally obsolete years ago [1], and
> has configured their mail systems to always reject, never bounce. [2]
for smtp, i agree. yet, uucp and other non-smtp last miles are not dead.
> [2] Yes, there are occasionally some edge cases of limited scope and
> duration that can be tough to handle. ... The key points here are
> "limited scope" and "limited duration". There is never any reason or
> need in any mail environment to permit these problems to grow beyond
> those boundaries.
so, a uucp-only site should have upgraded to real smtp by now, and by not
doing it they and their internet gateway are a joint menace to society?
that seems overly harsh. there was a time (1986 or so?) when most of the
MX RR's in DNS were smtp gateways for uucp-connected (or decnet-connected,
etc) nodes. it was never possible to reject nonexist...@uucpconnected at
their gateway since the gateway didn't know what existed or not. i'm not
ready to declare that era dead.
william herrin had a pretty good list of suggested tests to avoid sending
useless bounce messages:
No bounce if the message claimed to be from a mailing list.
No bounce if the spam scored higher than 8 in spamassassin
No bounce if the server which you received the spam from doesn't match
my domain's published SPF records evaluated as if "~all" and "?all"
are "-all"
i think if RFC 2821 is to be updated to address the backscatter problem, it
ought to be along those lines, rather than "everything must be synchronous."
--
Paul Vixie
KI6YSY