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

[Michael Rubel <[e-mail]>]

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
[e-mail]
https://www1.ietf.org/mailman/listinfo/asrg