Re: SPF is harmful. Adopt it.
"Peter J. Holzer" <[email protected]>
| Newsgroups | gmane.mail.im2000 |
|---|---|
| Message-ID | <[email protected]> |
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
> 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.
>
> ILT> This is not different from SMTP.
>
> 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".
> JdeBP> Second: Recipients, and recipient notification owners, can
> JdeBP> arrange to exchange information with one another about
> JdeBP> suspect message stores. Recipients can also choose to
> JdeBP> delegate the decision about whom they will pull mail from,
> JdeBP> to vetting services.
>
> ITL> This is not different from SMTP plus RBL and similar systems.
>
> It's certainly similar in concept, although it _is_ different. For one thing,
> in the SMTP case one is blacklisting clients, whereas in the IM2000 case one
> is blacklisting servers.
How does that make difference?
> For another, in the SMTP case blacklisting only
> takes effect _after_ some network traffic has occurred, whereas in the IM2000
> case blacklisting prevents _any_ network traffic from occurring.
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.
> However, you are changing your question. Your question was not how this was
> different to SMTP. It was:
>
> ILT> Why can't the spammer set up a zombie outgoing mail
> ILT> store on a hacked system, [...] ?
>
> The aforegiven shows that this is pointless because of the fact that the
> ostracism mechanisms in IM2000 can be easily augmented by information-sharing
> systems.
I don't see why the "ostracism mechanisms" in IM2000 should be more
effective than RBLs are now.
> JdeBP> (Think about it this way, if you like: A hijacker can _right
> JdeBP> now_ set up a web server on such a hijacked machine,
> JdeBP> publishing web pages of the hijacker's choosing. Yet we don't
> JdeBP> hear about an "unsolicited bulk web page" problem.)
>
> ILT> You may not have heard about it, but I have.
>
> No you haven't. The situation that you describe (apparently thinking that I
> wasn't aware of it, even though you simply repeated what I actually wrote)
> isn't an "unsolicited bulk web page" problem, and isn't described as such.
> People don't complain of "unsolicited" web pages being sent to them in "bulk"
> from such servers, because that's simply not what happens.
It isn't perceived as "unsolicited bulk web pages" by users, because
they see it in their mailer, but in fact a lot of spam looks very much
like spam via IM2000 would look like:
1) The spammer hijacks a lot of machines and sets them up as web servers
(the message stores).
2) The spammer hijacks a lot of machines (maybe the same as above, maybe
different) and uses them to send out mails which contain no or
invisible text and a <img/>-Tag pointing to the message store.
3) The user opens the mail, the MUA retrieves the image from the message
store and presents it to the user.
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.
hp
--
_ | Peter J. Holzer | I think we need two definitions:
|_|_) | Sysadmin WSR | 1) The problem the *users* want us to solve
| | | [email protected] | 2) The problem our solution addresses.
__/ | http://www.hjp.at/ | -- Phillip Hallam-Baker on spam
signature.asc
(application/pgp-signature, 189 B)
-----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.7 (GNU/Linux) iD8DBQFAS6BEfZ+RkG8quy0RAuoLAJ4jvOyvPNm2oeFzj/a1I1IQg+WpkQCeLffK ZvFFnCJSa5SLnF0N0GvxIqo= =HBTh -----END PGP SIGNATURE-----