Re: [Asrg] Some data on the validity of MAIL FROM addresses

[Michael Rubel <[e-mail]>]

mr> I agree with Yakov, and would even go further.  I think smtp-session
mr> reject is falling out of favor and will eventually disappear.

jk> Your evidence ?

Pretty thin, I'll admit.  Just my own experience.

mr> There are strong reasons to prefer accept-then-bounce or even filter to 
mr> reject.
mr> 
mr> (1) Reject gives feedback about your system to would-be bad
mr>     guys--including dictionary spammers--in a much faster and more 
mr>     reliable way.  Sysadmins rightly want to give out as little 
mr>     information as possible, because that's standard practice anywhere
mr>     security is involved.

jk> This is a variation of security through obscurity. And we know how well
jk> that works.

Okay,

  $ telnet merseymail.com 25
  Trying 193.110.243.34...
  Connected to merseymail.com.
  Escape character is '^]'.
  VRFY jrk
  252 VRFY not available
  QUIT

If obscurity is not useful in this situation, why refuse to VRFY?

I notice merseymail.com doesn't seem to be running ident either.

mr> (2) Reject is a less flexible mechanism.  Accept-then-bounce or filter 
mr>     allows recipients to work around certain obselete or overzealous
mr>     systems.

jk> How so?

One example:

http://www.mikerubel.org/computers/rmx_records/#notes_forwarding

Here's a better example.  Should mail that contains the string "sex" in the
subject line be Rejected during the smtp session?  Or does it make more
sense to carry that little piece of information through to spamassassin or a
Bayesian filter, where it can be combined with a lot of other information
about the message and recipient to make an intelligent decision?

Providing immediate Reject allows the spammer to keep trying until he's
sure the message has gotten through, and it allows him to learn about the
filtering behavior of your system or yourself.  In my opinion this is not
a desirable feature.  You're welcome to disagree, though.

mr> (3) Senders have come to understand that messages get incorrectly
mr>     filtered as spam sometimes; they no longer expect to recieve an
mr>     immediate rejection if there is a problem delivering a message.

jk> Which senders no longer expect this? All of them? You've asked them all?

If you send a blatently spam-like message to a mail host, do you expect to 
receive a bounce if it is not delivered?

mr> Like ident, smtp-reject has some usefulness inside private networks, but
mr> one shouldn't expect to see it widely used on the public Internet.

jk> Why compare this to ident? What's the point? And who says I shouldn't
jk> expect Best Practice on the public Internet (while being prepared for
jk> less).

Because "best practice" dictates that all domains would be run by
responsible admins, and that they would run ident.  The reasons people
aren't using ident are much the same: it leaks information about their
systems, but doesn't really buy them anything on the Internet, because not
everyone else is using it.

> If we really think that BCP30 is so hopelessly outdated, wouldn't this be a
> good place to start rewriting it.

I'm not familiar with BCP30...

Mike

_______________________________________________
Asrg mailing list
[e-mail]
https://www1.ietf.org/mailman/listinfo/asrg