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

From: "Jon Kyme" <[email-masked]>
Date: Tue, 20 May 2003 13:34:46 +0100

>Folks, the email operations world has increasingly moved away from
>real-time processing of SMTP data.
>

A colleague has just drawn my attention to the relevant part of rfc2505
(BCP 30) - for completeness here it is:

<quote>
1.5. Where to block spam, in SMTP, in RFC822 or in the UA

   Our basic assumption is that refuse/accept is handled at the SMTP
   layer and that an MTA that decides to refuse a message should do so
   while still in the SMTP dialogue. First, this means that we do not
   have to store a copy of a message we later decide to refuse and
   second, our responsibility for that message is low or none - since we
   have not yet read it in, we leave it to the sender to handle the
   error.

</quote>

I apologise for not thinking to reference this in my initial reply to the
point you raised.

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

---

From: "Eric Dean" <[email-masked]>
Date: Tue, 20 May 2003 10:56:23 -0400

Lemme tell you, I would love to perform SMTP rejects instead of bounces.
The problem is that anyone with any non-trivial amount of email has to run a
multi-level SMTP architecture.

Often, you have an MX server that accepts email and performs some rejects
due to various RFC criteria...however, once you accept that message..you are
obligated to handle it now.  If you then forward to a spam-filter server,
then strictly speaking you should bounce the message rather than silently
discard..but to each his own.

If you are running Exchange or Notes, it's a non-trivial interface to the
namespace to determine if a user is local...those who use a database can
often have the MX server and Email Application Server (POP/SMTP/HTTP) share
the same tables and therefore reject dictionary attacks rather than bounce
to non-existant email address (and watch the queue grow).  Sure, you can run
an LDAP interface to an Email server but often the dictionary attack is less
load.

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]On Behalf Of Jon
> Kyme
> Sent: Tuesday, May 20, 2003 8:35 AM
> To: Dave Crocker
> Cc: ASRG
> Subject: Re: [Asrg] Some data on the validity of MAIL FROM addresses
>
>

---

From: "Jon Kyme" <[email-masked]>
Date: Tue, 20 May 2003 16:25:47 +0100

> an LDAP interface to an Email server but often the dictionary attack is

Sorry, what? Your justification for not doing BCP is that it's
"non-trivial" to do it on the software you've chosen?

Is it just me, or is this completely arse upwards?

---

From: "Eric Dean" <[email-masked]>
Date: Tue, 20 May 2003 11:58:04 -0400

> "non-trivial" to do it on the software you've chosen?

Actually, I don't run those software packages I mentioned.  But yes, that's
not even a justification from the companies I've worked with..it's a fact
that they don't have the skills or people with the skills to manage these
systems and put together a BCP multi-tiered system architecture that
performs rejects rather than bounces...but then again, I'm hoping it keeps
me employed.

> Is it just me, or is this completely arse upwards?

It's absolutely arse-upwards.  People don't know how to deal with spam.
It's very difficult to handle in large companies.  AOL receives nearly a
billion spam per week...that's non-trivial.

---

From: Yakov Shafranovich <[email-masked]>
Date: Tue, 20 May 2003 13:58:06 -0400

>    have not yet read it in, we leave it to the sender to handle the

See RFC 2821, section 3.1.:

---snip----
    However, in practice, some servers do not perform recipient
    verification until after the message text is received.  These servers
    SHOULD treat a failure for one or more recipients as a "subsequent
    failure" and return a mail message as discussed in section 6.
---snip----

Even thought it might be recommended to do processing in real-time, in 
practice many systems do not and will not. We must be take that into account.

---

From: Michael Rubel <[email-masked]>
Date: Tue, 20 May 2003 12:05:55 -0700 (PDT)

> practice many systems do not and will not. We must be take that into account. 

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

There are strong reasons to prefer accept-then-bounce or even filter to 
reject.

(1) Reject gives feedback about your system to would-be bad
    guys--including dictionary spammers--in a much faster and more 
    reliable way.  Sysadmins rightly want to give out as little 
    information as possible, because that's standard practice anywhere
    security is involved.

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

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

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

Mike

---

From: "Jon Kyme" <[email-masked]>
Date: Tue, 20 May 2003 21:01:07 +0100

> > practice many systems do not and will not. We must be take that into

Of course we must. We shouldn't assume Best Practice to be done by others.
Best Practice is what we should try to do ourselves.

> reject is falling out of favor and will eventually disappear.

Your evidence ? For goodness sake, *hotmail* do it. Of course they may be
going to stop at any minute - in which case I'll look silly.
 
>     information as possible, because that's standard practice anywhere

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

>     allows recipients to work around certain obselete or overzealous

How so?

>     immediate rejection if there is a problem delivering a message.

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

> one shouldn't expect to see it widely used on the public Internet.

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

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

Jon (tired) Kyme

---

From: Michael Rubel <[email-masked]>
Date: Tue, 20 May 2003 13:25:42 -0700 (PDT)

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.

> good place to start rewriting it.

I'm not familiar with BCP30...

Mike

---

From: Daniel Feenberg <[email-masked]>
Date: Tue, 20 May 2003 16:35:11 -0400 (EDT)

>     immediate rejection if there is a problem delivering a message.

Does everyone doing wrong have to work so hard to entice others into sin
as some members of this list are wont to do?

Accept and discard is a very bad system. I understand that some software 
will do content filtering no other way, but that doesn't make it worthy
of advocacy. 

If you use it, primarily your customers/users will be the losers, but why
encourage others to do the same? It raises the possibility of false
positives disappearing into black holes into a certainty, removes any
chance of directing the customers of spam friendly ISPs to instructive web
sites explaining why their mail was rejected, and generally relieves
spam-friendly ISPs of ever having to explain to customers why their mail
is being lost. 

Is it possible to seriously claim it is a "security precaution" - there is 
no shame on this list?

If widely adopted, it would discourage rather than encourage spam
prevention technology, as all missing mail would be blamed on spam
control.

With respect to (3), legitimate users may not expect immediate rejection,
but they expect some notice, and a DSN notice for spam is not very
practical, since there is no verifiable address to send it to. Do you send
a DSN for undeliverable spam? For deliverable spam?

Now that half of email is spam, is it really believable that accepting all
mail and processing spam rejections later will increase capacity? 

Lastly, the last time I looked at the Maps site, they had instructions for
virtually every MTA written in the last decade, and many earlier ones. So
at the very least, RBLs can be used (and will reject at SMTP dialog) by
nearly any site. It is only content based filters that may not be easily
used before the connection is completed.

---

From: Michael Rubel <[email-masked]>
Date: Tue, 20 May 2003 15:01:16 -0700 (PDT)

> as some members of this list are wont to do?

Ha!  I only wish my sin-enticement skills were that good.  I'd be at home
with my harem right now.

Seriously, I wasn't trying to start a religious war here.  Just pointing
out the obvious: that the use of spam filters is increasing, that those
filters send as little information back to the spammer as possible, and
that sysadmins can and will take steps to keep their user lists private.

Would it be nice if everyone provided accurate whois, vrfy and ident
services, and gave the sender of each refused smtp transaction a detailed
summary of why the decision was made to refuse it, so that the sender
could correct the problem and try again?  Yup.  But be realistic--it ain't
gonna happen.

Mike

---

From: Vernon Schryver <[email-masked]>
Date: Tue, 20 May 2003 16:33:03 -0600 (MDT)

> From: Michael Rubel <[email-masked]>

> ...

That suggests the underlying assumption behind saying that SMTP status
codes are obsolete.  In fact, SpamAssassin is like every other filter
at least in principle.  SpamAssassin is often run during the SMTP
session using a sendmail milter hook.  If SpamAssassin computes a
spamish score for the message, the message can be rejected.  See
http://www.google.com/search?q=spamassassin+milter

> filtering behavior of your system or yourself.  

No, you hide no information by giving it with a DSN instead of an SMTP
status response.  If you don't want to tell the spammer that the
message was detected as spam, then delaying the detection is irrelevant.
You won't be sending either a bounce or a negative SMTP status response.

> ...

What is a blatently spam-like message and in whose eyes?  If you
send a message that you don't think is blatently spam-like, don't
you expect an indication that it was rejected?

If you send what I define a blatently spam-like message, you'll receive
250 OK SMTP status codes and no DSN.  That violates offical as well
as some common sense BCPs, but its necessary to protect spam traps.

> ...
> responsible admins, and that they would run ident. 

I think that's wrong.  I think no BCP says anything good about IDENT.
If I'm wrong, please point out the RFC (whether in the BCP index or
not, other than ) that strongly recommends IDENT.

>                                                     The reasons people

I think that's half wrong.  IDENT need not leak anything, but it is
of very little use.  (An IDENT answer has meaning only in the context
of the IDENT server's logs, user database, and so forth.  Thus, contrary
to RFC 1413, every IDENT answer could be purely synthetic and related
to the real answer only by a log entry on the server.)

> I'm not familiar with BCP30...

I don't want to insult you, but that is definitely the wrong answer here.
An acceptable answer might be something like "give me a little while to
read and understand BCP 30."  The privilege of speaking here carries the
responsibility of an honest effort to read the relevant document.

See http://www.rfc-editor.org/rfc.html
and especially http://www.rfc-editor.org/bcp-index.html

Vernon Schryver    [email-masked]
_______________________________________________
Asrg mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/asrg

---

From: Yakov Shafranovich <[email-masked]>
Date: Tue, 20 May 2003 19:10:57 -0400

>will do content filtering no other way, but that doesn't make it worthy

To both the devils and the angels :)

Practically speaking, both accept and discard, and reject at SMTP level 
will be around for a while. It is highly unlikely that the entire Internet 
will move over to one or the other. Additionally, both have their pros and 
cons, and its upto to the specific system admin to figure out which one is 
better. We as ASRG, must account for both.

Yakov

---

From: Michael Rubel <[email-masked]>
Date: Tue, 20 May 2003 16:34:49 -0700 (PDT)

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..."

> 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

---

From: Vernon Schryver <[email-masked]>
Date: Tue, 20 May 2003 18:24:14 -0600 (MDT)

> information about your system or your filters back to the spammer, they are

What information about your system or filters is leaked to the spammer
by SMTP status codes that is not leaked by DSNs?  What information is
leaked by status codes regardless of whether it is leaked by DSNs?

Of that leaked information, which cannot be protected if you choose
by not saying too much in status messages or DSNs?

> address, and can be implemented so as to leak it very slowly....

What is that leaked information?

> system load argument, that is.

For one thing, some spam has forged sender information.  DSNs for that
spam will be sent to innocent people, clogging their mailboxes, and
worrying them.  People are often quite worried by bounces for mail
they didn't send.

For another, in principle spammers might distribute spam using DSNs, bouncing
millions of messages. 

I wish I didn't suspect you'd fix both of those problems by also turning
off DSNs.

No great crystal ball is needed to know that the consensus among IETF
participants will be to include enough information in DSNs and STMP
status messages to allow senders to figure out what happened.  This
is not only because too many of us are engineers of various sorts who
have to figure out what went wrong and so value such information.  It
is also because the bread and butter of many of us depends in part on
email.  When your living depends on email, you do not like false
positives from spam filters and you really do not like silent false
positives.

---

From: Kee Hinckley <[email-masked]>
Date: Tue, 20 May 2003 20:54:04 -0400

We've been through this before.

Spam is in the eye of the beholder.
Therefore some spam filtering rules need to be per-user.
Milter's (and many other systems) don't give you enough information 
to determine who the final recipient is--not to mention that their 
may be more than one, with different standards.
Therefore it is not always possible to reject things at the SMTP level.
But yes, everyone agrees that you should if you can.
Therefore--encourage it, but don't depend on it.
Can we move on?
-- 
Kee Hinckley
http://www.messagefire.com/          Junk-Free Email Filtering
http://commons.somewhere.com/buzz/   Writings on Technology and Society

I'm not sure which upsets me more: that people are so unwilling to accept
responsibility for their own actions, or that they are so eager to regulate
everyone else's.
_______________________________________________
Asrg mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/asrg

---

From: Vernon Schryver <[email-masked]>
Date: Tue, 20 May 2003 23:07:45 -0600 (MDT)

> From: Kee Hinckley <[email-masked]>

> We've been through this before.

Really?  I must have been asleep, because I don't remember.

> Therefore--encourage it, but don't depend on it.

You can move whenever and wherever you wish.  I prefer to move with
an accurate map instead of capricious prejudice.

In fact the sendmail milter interface generally gives sufficient
information for per-user rules during the SMTP transaction.  That's
how the DCC sendmail-milter interface, dccm, is able to support per-user
white/blacklists.  The DCC source even includes a CGI interface for
user point-and-click fiddling with per-user white/blacklists based on
per-user directories of suspect messages.  That no DCC users like it
even enough to say it needs improvement suggests I'm an exceptionally
bad GUI designer.

I don't know but assume that the SpamAssassin milter interfaces (I
think there are two) use the same information for per-user rules and
scoring; it certainly could.  I don't know but suspect the milter
mechanism does not handle .forward files, but I don't think that's a
significant problem.  The milter mechanism handles alias files and at
least some other things that cause sendmail to forward the message
elsewhere in the sense of telling the milter filter program as much.

The biggest practical problems I can think of for per-user filters
using the milter mechanism are that sendmail wants to do things
with the UID "daemon" or equivalent and that the SMTP protocol
doesn't let the SMTP server answer the DATA command with "250-ok
for Rcpt #1, 550-spam for Rcpt #2, and 450-try-later for Rcpt #3."

Moreover, whether some or all current MTAs do or don't give you enough
information to determine the final recipient is an implementation
choice that is irrelevant here.  The BCP and long standing recommendation
and practice that an MTA should figure out the validity of each Rcpt_To
value as it is presented implies that an MTA designer ought to have
the final recipient figured out before saying "250 OK" or "550 Bad".

---

From: "Jon Kyme" <[email-masked]>
Date: Wed, 21 May 2003 08:59:33 +0100

> Therefore--encourage it, but don't depend on it.

I think that now we're all in agreement that 
(a) spam filtering should be per-user
(b) we should reject in SMTP where possible

We can probably agree that we could profitably work towards per-user
filtering in a way that enables rejection in SMTP.

So yes, let's move on.

---

From: "Jon Kyme" <[email-masked]>
Date: Wed, 21 May 2003 10:25:44 +0100

>for Rcpt #1, 550-spam for Rcpt #2, and 450-try-later for Rcpt #3."

Personally, I think the easiest solution to this problem is to modify the
semantics of 250 after DATA such that in the case of a message with
multiple RCPT TO we shouldn't *require* that a notification be generated
for a "delivery failure" if this "failure" is an action requested by a
mailbox "owner".

Such a change would effectively give different QOS to the two classes of
messages.

If a sender needs the higher QOS then it needs to stick to one RCPT TO per
message, a sender that doesn't need it (or doesn't care) can
bundle them.

---

From: Richard Rognlie <[email-masked]>
Date: Wed, 21 May 2003 06:06:13 -0400

> for Rcpt #1, 550-spam for Rcpt #2, and 450-try-later for Rcpt #3."

Which is where LMTP is better than SMTP...   If only mail.local, etc.
supported milter as well (during LMTP delivery)

-- 
 /  \__  | Richard Rognlie / Oracle Prophet / Gamerz.NET Lackey
 \__/  \ | http://www.gamerz.net/rrognlie/    <[email-masked]>
 /  \__/ | Today is the first day of the rest of your life.  Of course,
 \__/    |    so was yesterday, and look how you screwed *that* up...
_______________________________________________
Asrg mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/asrg

---

From: Kee Hinckley <[email-masked]>
Date: Wed, 21 May 2003 08:12:21 -0400

>information for per-user rules during the SMTP transaction.  That's

I wasn't trying to single out milter's specifically.  What we've 
discussed, over and over, is the fact that you can't always know the 
final recipient at the time of receipt (even though you may know it's 
a valid address).  I don't see the need for us to go into it over and 
over again.

>elsewhere in the sense of telling the milter filter program as much.

.forward's were one thing.  The other is a standard system where the 
gateway mail system is outside of the firewall, but additional 
delivery is done inside the firewall.

But anyway.  I'm just don't see that this conversation is generating 
anything except heat.
-- 
Kee Hinckley
http://www.messagefire.com/          Junk-Free Email Filtering
http://commons.somewhere.com/buzz/   Writings on Technology and Society

---

From: Vernon Schryver <[email-masked]>
Date: Wed, 21 May 2003 08:40:57 -0600 (MDT)

> I wasn't trying to single out milter's specifically.

I misunderstood your words to be unambiguously asserting that the
milter mechanism does not include the end user identity.

>                                                       What we've 

> delivery is done inside the firewall.

We have agreed is that as people configure and run STMP servers for
various good and bad reasons, an SMTP server may not know the final
address and so may have problems doing proper spam filtering.

However, that fact does not imply that filtering cannot be done before
the end of the SMTP transaction or that it is not best done then.
You seem to be asserting to the contrary that filtering must or should
be done primarily during final delivery.  We certainly have not agreed
on that, although there have been some recent statements by others in
support of that view.

That fact also does not conflict with the fact that most filtering
could be done during the STMP transaction given perhaps onerous efforts
to synchronize user databases, whitelists, logs, and so forth among
SMTP servers.

I suspect that most filtering today does not need any synchronizing
among SMTP servers but could be done during the SMTP transaction given
appropriate filtering software.  For example, it sounds as if the
SpamAssassin milters need work.

None of that implies that additional filtering during final delivery
cannot or must not be done.

> But anyway.  I'm just don't see that this conversation is generating 

An IETF/IRTF working group mailing list is not like netnews or SPAM-L.
It is not merely a forum for stating positions and exchanging views.
It is a tool for generating and guaging consensus on technical issues.
Regardless of heat, this mailing list must address the issue of whether
filtering SHOULD (in the special meaning of RFC 2119) be done during
the SMTP transaction.  If we can't reach consensus on such a fundamental
and simple issue, then this mailing list is distinctly worse than useless.

---

From: "Jon Kyme" <[email-masked]>
Date: Wed, 21 May 2003 15:50:33 +0100

> a valid address).  I don't see the need for us to go into it over and 

Did I miss something? Anyway, even if you can't always know, the important
question is how often you can know, what can you do to know more often and
what you do when you really can't tell.

> delivery is done inside the firewall.

One can do "callforward recipient verification". It's perfectly possible -
it might be *way* expensive. Or the outside mail system can access the same
data as inside systems - one way or another. The problem isn't inherent in
SMTP is it? but in the way admins have traditionally set up multi-tier mail
systems. It's an implementation thang.

> But anyway.  I'm just don't see that this conversation is generating 

I don't know, it seems pretty good-natured so far - and there are (IMHO)
important implications for reliability in an MTS implementing anti-spam
stuff.

Of course the discussion has veered away from the thread subject a bit.

---

From: "Tom Thomson" <[email-masked]>
Date: Wed, 21 May 2003 18:14:28 +0100

> and simple issue, then this mailing list is distinctly worse than useless.

That's true. Since filtering in some form is probably going to be some part
of any realistic solution we ought to be able to get a handle on how things
behave when a filter intervenes.

I don't think there's a simple answer.  I would like to base the answer
around the idea that some types of filtering can appropriately be treated as
being the same as the end-user discarding the mail from his inbox, while
others are more like the MTA being unable to deliver. But there's also the
question of not sending bounces to forged Mail_From addresses. Here are some
ideas:

We can consider 4 main cases.

1) the filter simply diverts mail into the users junk mail folder, or in
some wasy annotates it so that the MUA will show it as probable spam.  In
this case the MTA must not bounce and must not reject in the SMTP
transaction, since the mail is being delivered correctly.

2) the filter discards mail based on content (including content headers) and
not solely on the envelope. There are a couple of subcases here:
(a) the end-user (envelope recipient) has expressed a desire not to receive
this mail: in this case I can't see that it's any different (so far as the
sender is concerned) from the end user noticing it in his inbox and deleting
it.  The MTA should not reject during the SMTP transaction and should not
generate a bounce.
(b) this is nothing to do with the end user, it's MTA policy - so the mail
was undeliverable by this MTAs rules. Here I think the MTA should generate a
bounce but may reject the mail in the SMTP transaction if the sender is
pipelining - sending the data before knowing whether there is an error.

3) the filter discards mail based on the smtp envelope only. Since the end
user doesn't see the envelope, only the content, there's no way an end user
could base a decision to delete mail from his inbox based on the envelope -
the mail is undeliverable, and the MTA must say so. This should be done
using an error response within the smtp transaction. If the sender is
pipelining and has closed the connection before an error can be raised, a
bounce may be generated.

4) This consideration overrides 2 and 3 above: Because we don't live in an
ideal world, bounce messages may be bad news.  An MTA which can detect
envelope forgery (using RMX or Cryptographic Authentication or HELO domain
non-existence forward Received-From: chain verification or whatever other
future or existing it may have) and discards a message which it knows to be
forged MUST NOT generate a bounce.

Tom

---

From: Barry Shein <[email-masked]>
Date: Thu, 22 May 2003 00:12:10 -0400

> (b) we should reject in SMTP where possible

Plus or minus begging the use of the conditional "should" I'm not
necessarily in agreement.

Unfortunately, spam is often (nearly) indistinguishable from a
denial-of-service attack.

As I've reported here previously I've had the same spam spewing
simultaneously from over 200 different IP addresses.

You can't limit your response to such an attack to walking up to each
door in the neighborhood and knocking and seeing if the lady or
gentleman of the house is available and waiting for them to pull some
clothes on so you can all sit down and have nice cup of coffee and
proceed to explore together whether this battery of incoming cluster
bombs moving at mach 2 might actually be something they want.

If you get my drift.

  > Spam is in the eye of the beholder.

So are denial of service attacks.

I claim spam is looking more and more like DoS than just a little
annoying junk to sort through.

-- 
        -Barry Shein

Software Tool & Die    | [email-masked]           | http://www.TheWorld.com
Purveyors to the Trade | Voice: 617-739-0202        | Login: 617-739-WRLD
The World              | Public Access Internet     | Since 1989     *oo*
_______________________________________________
Asrg mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/asrg

---

From: Kee Hinckley <[email-masked]>
Date: Fri, 23 May 2003 19:59:24 -0400

Some anecdotal evidence in the "what will they do if you make them 
have a real from" category.

Domain:		netoes.com
Content:	Printer Cartridge Spam
From:		[email-masked]
Return-Path:	[email-masked]

Domain contact has fake phone number
Web page is empty (but has the title e-i1.com, also an empty page)
No PTR lookup on the IP addresses.

The Return-Path does send a 250.  In fact a little testing shows that 
*any* non-relayed address sent to smtp.netoes.com will be accepted.

They appear to have a number of different IP addresses
64.95.116.98, 63.251.54.72, 64.95.116.101...
But they all hang right off of border5.ge4-1-bbnet2.sfo.pnap.net.

So.  There he sits, "validating" every message sent.

Mind you.  I'd still like to see a better way to validate From 
addresses, and I do think it would help the spam situation.  But...
-- 
Kee Hinckley
http://www.messagefire.com/          Junk-Free Email Filtering
http://commons.somewhere.com/buzz/   Writings on Technology and Society