mr> Here's a better example. Should mail that contains the string "sex" in the
mr> subject line be Rejected during the smtp session? Or does it make more
mr> sense to carry that little piece of information through to spamassassin or a
mr> Bayesian filter, where it can be combined with a lot of other information
mr> about the message and recipient to make an intelligent decision?
vs> That suggests the underlying assumption behind saying that SMTP status
vs> codes are obsolete.
That's right, I'm saying that where SMTP status codes leak useful
information about your system or your filters back to the spammer, they are
obselete.
vs> In fact, SpamAssassin is like every other filter at least in principle.
vs> SpamAssassin is often run during the SMTP session using a sendmail
vs> milter hook. If SpamAssassin computes a spamish score for the message,
vs> the message can be rejected. See
vs> http://www.google.com/search?q=spamassassin+milter
I know it's possible, Vernon, but I don't think that it's a good idea. I
want to give spammers as little information to work with as possible. If it
means my messages occasionally end up dumped as false positives, that's a
price I'm willing to pay.
mr> Providing immediate Reject allows the spammer to keep trying until he's
mr> sure the message has gotten through, and it allows him to learn about the
mr> filtering behavior of your system or yourself.
vs> No, you hide no information by giving it with a DSN instead of an SMTP
vs> status response. If you don't want to tell the spammer that the
vs> message was detected as spam, then delaying the detection is irrelevant.
vs> You won't be sending either a bounce or a negative SMTP status response.
We don't disagree here. I have no problem with SMTP responses that do not
leak information. It's the ones that leak information I have a problem
with. DSN's only leak information if a spammer gives his true return
address, and can be implemented so as to leak it very slowly. They may be
a reasonable compromise.
But I think it would be better to not send any notification whatsoever
until the final recipient has made a filtering decision. I can imagine
situations where a user has a .forward file in a blacklisted or otherwise
normally-filtered domain, and might need to work around domain-based
spamfilters to allow the forwarding to happen. Or perhaps the user wants
to implement special whitelisting and blacklisting, or has his/her own
Bayesian filter, or wants to operate in "stealth" mode. User policy may
be more or less strict than normal system policy.
Can you think of a good reason *not* to hold off on sending a DSN until
the final (user's) filtering decision has been made--for example, when the
message gets dumped in the recipient's "spam" folder? Apart from the
system load argument, that is.
mr> If you send a blatently spam-like message to a mail host, do you expect to
mr> receive a bounce if it is not delivered?
vs> What is a blatently spam-like message and in whose eyes? If you
vs> send a message that you don't think is blatently spam-like, don't
vs> you expect an indication that it was rejected?
I'd not be surprised if I didn't receive one. I certainly don't and
shouldn't expect a bounce during the SMTP transaction.
mr> Because "best practice" dictates that all domains would be run by
mr> responsible admins, and that they would run ident.
vs> I think that's wrong. I think no BCP says anything good about IDENT.
vs> If I'm wrong, please point out the RFC (whether in the BCP index or
vs> not, other than ) that strongly recommends IDENT.
Fair enough. I retract the statement, and instead begin it with: "In an
ideal world, all domains..."
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...
I don't want to insult you, but that is definitely the wrong answer here.
Mea culpa. You're right, I've read rfc-2505 (BCP-30), and should have
done so before responding the first time. It hasn't changed my opinion
though.
Mike
_______________________________________________
Asrg mailing list
Asrg(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/asrg