On Wed, 17 Mar 2004, Robert G. Brown wrote:
a) Preparse the header so that the entire delivery path is the primary
content of the message, with the message itself added (header intact) as
an attachment.
This is true now. Many people don't know how to parse the headers, but it
obeys a specific syntax and is machine parseable.
b) Return the complaint as mail to postmaster of the originating
network with a special error code that would allow it to be counted and
digested easily. One doesn't want to create a new kind of DoS attack on
postmaster, and making it easy and automatic to return a complaint COUNT
of some sort on otherwise identical content can help prevent that while
making it easier for SP admins to deal with mounting complaint levels.
This is possible now, and SpamCop does this. The problem with SpamCop is
that they alter the message, making it useless. SpamCop complaints are
routinely deleted as a result. I usually forward them on to customers
with an FYI that we don't consider such to be a valid complaint, but they
may want to be aware of what someone said.
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.
Proxies are another story. I don't know of any genuine reasons to run open
proxies, though closed proxies (web caches) are clearly useful. I don't
know of anyone claiming they are useful. But neither does that mean they
have no use. However, as a service provider, I would say this much: If a
customer found a useful reason to have an open proxy, then I would only
insist that they keep logs of its use. This is easy to place in a contract
or AUP.
d) Take steps to ensure that SPs run a postmaster address, and maybe
There is already a BCP for this. Rarely is this a problem.
come up with things like Jeff Chase was proposing to continuously
measure their responsiveness to spam/virus-class bounce messages and
globally blacklist the worst (least responsive) offending SPs. Etc.
How would you define "responsiveness"? Does it mean getting an
auto-responder message? Does it mean getting a message saying something
had been done? You cannot give out certain information about customers.
Basically, all you can do is send an auto-responder message and a notice
that the ticket was closed. That doesn't indicate what happened, nor does
it indicate who the spammer was, or if the ISP agreed they were a spammer.
Sometimes the action is obvious if, say, a website disappears. But how do
you know they took action against a dialup customer? You can't.
"Continuous measurement" is the same as a DOS attack. A ping flood is a
continous measurement of the bandwidth available and its responsiveness.
That's why there is a -f option to ping. Unauthorized measurements are
illegal.
Right now enabling SPs are insulated from any kind of RFC-based
responses or complaints about spam because MUA's and MTA's have no
predefined protocol for generating such a response in a constructive
way.
??? I'm not sure what you mean. By the time you -read- a spam, it is
delivered, and the SMTP protocol has long since finished. Spam isn't the
only kind of abuse that an ISP responds to. The abuse@<isp> works pretty
well, since you can forward the complained-of message. There are some
things I'd like MUA's to do, such as include the whole headers(some MUA's
do, some MUA's don't), but that isn't an RFC issue, either.
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.
--Dean