ietf
[Top] [All Lists]

Re: "Principles" of "Spam-abatement"

2004-03-17 14:47:09


Dean Anderson wrote (in part):

 c) Work out what to do about relays and proxies, again to prevent
man-in-the-middle DoS more than anything else.  One site should not be
able to generate mail that it "forwards" with fictitious headers and
evil content so that it appears to come from some hapless but innocent
network.

Relays don't add ficticious headers, nor do they add evil content.  They
may place their (true) headers on top of ficticious headers.  They cannot
verify that the headers given are accurate. This is true of all relays, open or closed.
Sounds like his first point - fix it so they are checkable. If I am going to relay
for X number of domains, it seems reasonable that we share some kind
of shared key or password so they the headers they pass me can be verified.

Most complaints/bounces that are automatically generated by
antivirus software or reported by humans (I've read plenty of both:-(
are hopeless and de facto useless without several rounds of
communications, and sometimes not even then: the humans don't even know
what a mail header IS and often have no way of knowing or suspecting
that the From address is bogus or sending in the real header so it can
be parsed by the SP postmaster.  Antivirus software developers should
know better (damn it!) but even THEY don't bother to parse the header or
include the header in the stupid bounces they generate, or validate
any sort of correspondance between originating host and From address.

Yes, it would be good to send the entire headers.
But users should know that the from: header can be forged. They should
also know some other things about email and the internet, such as don't
open attachments you aren't expecting. If you get an unexpected
attachment, ask the person if they sent it. This is an education problem.
There is (1.0) legal spam and (2.0) illegal spam.

Illegal spam can be (2.1) advertisements or (2.2) viruses.

(1.0) Is most often traceable using the headers and content.
         This is getting easier to stop and there can be things done
         to make it easier - a computer parseable unsubscribe link and
          a standard protocol to unsubscribe.

(2.1) Often is traceable by the content, and almost never by the headers.
Content filters and blacklists of some kind can catch these and throw
         them in the trash or hang-up when the content matches a URL that
         somehow blacklisted.

(2.2) Is for a virus scanner to catch and is almost never traceable.

There are things the IETF can do to help with the spam problem (1.0).

--

Doug Royer                     |   http://INET-Consulting.com
-------------------------------|-----------------------------
Doug(_at_)Royer(_dot_)com                 | Office: (208)520-4044
http://Royer.com/People/Doug   | Fax:    (866)594-8574
                              | Cell:   (208)520-4044

             We Do Standards - You Need Standards


Attachment: smime.p7s
Description: S/MIME Cryptographic Signature