Re: SPF is harmful. Adopt it.

>On 2004-03-07 11:33:56 +0000, Jonathan de Boyne Pollard wrote:
>> JdeBP> First: Recipients can choose to give different priorities to
>> JdeBP> notifications according to whether they "know" the message
>> JdeBP> stores that those notifications reference.  So a recipient
>> JdeBP> could instruct his/her recipient MUA that it "knows" AOL's=20
>> JdeBP> and Sally's message stores.  "New" mail on any other message
>> JdeBP> stores would then be flagged as residing on an "unknown"
>> JdeBP> message store, when the list of "new" mail is displayed.
>>=20
>> ILT> This is not different from SMTP.
>>=20
>> Yes, of course it is.  SMTP-based Internet mail is a "store and forward"
>> system.  A recipient cannot tell the difference between a hijacked machine
>> running an SMTP Relay puppet and an unknown MTS forwarding mail.  IM2000,
>> _not_ being a "store and forward" system, does not have this ambiguity.
>
>I fail to see the difference.
>
>Where exactly is the difference between an unknown MTA sending mail from
>an unknown mail address and an unknown IM2000 agent sending a reference
>to an unknown message store? In both cases the message can be be flagged
>as "suspicious".

With IM2000, the message itself isn't necessarily sent, so it's much
easier to leave it up to the recipient, and whatever policies he
implements to do so, to choose whether to "pull" the actual message
content from the server.

Further, as the message notification is relayed from host to host, the
fact that the message store is "suspicious" need not be determined,
nor relayed, until it reaches an agent that needs or wants to know
that information.

Whereas, with SMTP, as a message gets relayed from host to host, along
with the message content, the "suspicious" nature of it either has to
be determined and flagged up-front, or the information needed to
determine its nature gets buried (mainly, in the form of "Received:"
headers) further and further down in the message itself.

How/whether IM2000 will handled message *content* relaying remains to
be seen; if it does, it'll have some of the same issues, but, as a new
protocol, there's an opportunity to do it "right", by not putting
transit (or envelope) information in the message content, rather, in,
or "on", the envelope, where it belongs.

>> JdeBP> Second: Recipients, and recipient notification owners, can
>> JdeBP> arrange to exchange information with one another about=20
>> JdeBP> suspect message stores.  Recipients can also choose to=20
>> JdeBP> delegate the decision about whom they will pull mail from,=20
>> JdeBP> to vetting services.
>>=20
>> ITL> This is not different from SMTP plus RBL and similar systems.
>>=20
>> It's certainly similar in concept, although it _is_ different.  For one t=
>hing,
>> in the SMTP case one is blacklisting clients, whereas in the IM2000 case =
>one
>> is blacklisting servers.
>
>How does that make difference?

Presently, certainly in the past, it was easier on many systems to
block arbitrary internal user ("customer", "client") to an internal
queue (e.g. potentially outgoing email) than to an outgoing network
port (e.g. 25/tcp, for outgoing SMTP email).

Therefore, many people are still of the mind-set that it's
architecturally sound for a system to be able to distinguish between
connections *incoming* from a given IP address and *outgoing*
connections made to a reserved port on that same address, in terms of
distinguishing between "arbitrary, possibly unpoliced users on the
system" and "presumably locked-down service offered by the system".

It is, in fact, *not* architecturally sound to do that.  Today, most
deployed systems that usefully support arbitrary users allow blocking
their access to outgoing port 25 just as they allow blocking their
access to an internal service such as an outgoing message store.

Therefore, I'm of the opinion that IM2000 does not *usefully*
distinguish between unpoliced message-notifying clients and policed
outgoing message stores, given an untrusted IP address that is serving
as the source and destination of both, respectively, at least not
sufficiently to justify a rollout of IM2000.

What the SMTP ecosystem already offers to mitigate this concern, after
all, is IDENT lookup.  If you trust an IP address to contain a
working, policed server of messages (such that you can trust it when
it is working as an SMTP client to inject messages into your system),
all you need is for it to properly serve IDENT information for a
connection you get from that system.

And if you trust the IDENT information to disambiguate the policed MTA
(SMTP server, acting as a client) from arbitrary users (who might be
running rogue SMTP clients), then you have all you need to make the
same sort of distinction IM2000 offers here.

And, note that IDENT seems to be poorly used or supported, even though
it's ages old, probably very easy to set up (compared to an IM2000
outgoing message store, anyway), and well-understood at a conceptual
level, though there is the problem of, AFAIK, not having some standard
means to say "this connection is coming from my SMTP server, not some
random luser on my system" via an IDENT string, a problem which IM2000
would *not* have.

>> For another, in the SMTP case blacklisting only
>> takes effect _after_ some network traffic has occurred, whereas in the IM=
>2000
>> case blacklisting prevents _any_ network traffic from occurring. =20
>
>You have that backwards. In SMTP, the client is backlisted by
>IP-address. The blacklisting can take effect as soon as its IP address
>is known, which is as soon as the first IP packet is received (although
>it is usually not done until after the TCP handshake or even until the
>SMTP envelope has been transmitted). If you blacklist servers in IM2000,
>you have to wait until the reference to the message store has been
>transmitted, which is probably about as much traffic as an SMTP
>envelope.

He was referring to message *content* traffic.  And I'm not sure how
you believe it's useful to blacklist servers in IM2000 without
receiving references to their message stores -- how is that different
from blacklisting clients in SMTP without receiving incoming SMTP
traffic from them?

As to the IM2000 traffic needed to transmit an SMTP envelope: it'll be
substantially less for vanilla IM2000 than for vanilla SMTP, since
it'll (probably) be done without greetings, HELO/EHLO, or separate
non-pipelined MAIL FROM and RCPT TO transactions.

It won't be a *lot* less, though.  And there'll be a ton *more*
traffic, again for vanilla implementations, for mailing-list exploders
receiving a single message, since all those receivers are each going
to independently "pull" that message, instead of the SMTP server
itself replicating it locally.

>In SMTP the simple fact that the mail is HTML and contains only a
>reference to an image is a good indicator that it is spam. But in
>IM2000, all messages contain only a reference to the message, so that
>distinction is lost.

Well, all messages are *pulled* by recipients, rather than *pushed*,
to the extent they need to see them to make decisions about whether
they are spam.

A big advantage of IM2000 here is that the decisions can be left to
recipients whether to bother "pulling" a message at all, and that
recipient might have enough info to make that decision, without having
to transmit his criteria upstream to his SMTP server, and that server
upstream to any SMTP relays acting on its behalf, and so on.

A big disadvantage of IM2000 is that, by leaving the decisions to
recipients, a given UBM that many recipients on a site are told about,
and that they *don't* recognize as spam without seeing the content,
results in *all* those recipients independently "pulling" down that
content in order to determine that it's spam.

Whereas, with SMTP, local replication (assuming multi-RCPT is used)
reduces the costs of that somewhat.  The recipients still check their
copies against their spam-detection policies, but they do so on copies
already made *locally*.

Of course, recipients can "share" info on suspected spam with each
other (anonymously via a system-wide service, perhaps) in both
paradigms.  That might save useless "pull" operations in IM2000; but
it'd save useless spam scanning in SMTP, which is the problem that
remains after network transmission of the content has already been
dealt with, so it's useful there as well.

By essentially mandating multiple downloads of message content by
multiple receivers of the same message, IM2000 sort of assumes network
bandwidth and high availability are cheap.  Which makes me wonder, if
they're so cheap, why is IM2000 so much better than SMTP, other than
as a somewhat-better protocol that locks its users into *different*
choices than does SMTP?

-- 
James Craig Burley
Software Craftsperson
<http://www.jcb-sc.com>