On Sun, 09 Feb 2003 20:21:42 PST, Adonis El Fakih
<adonis(_at_)aynacorp(_dot_)com> said:
I have submitted an Internet draft
http://www.ietf.org/internet-drafts/draft-fakih-amdp-00.txt to ietf
discussing the protocol along with its pros and cons. I also outlined an
implementation guideline to enable developers to implement the protocol
ASAP . I was also able to develop a demo implementation and tested it
and the basic delivery system seems to work as described in the
document.
I've read through the draft, and find nothing that can't either already be done
in the current context of ESMTP and already-existing error codes and SMTP
extensions, or isn't a generally bad idea engineering or security wise.
A whole class of things addressed here (authentication and confidentiality)
were addressed in RFC1847:
1847 Security Multiparts for MIME: Multipart/Signed and
Multipart/Encrypted. J. Galvin, S. Murphy, S. Crocker, N. Freed.
October 1995. (Format: TXT=23679 bytes) (Status: PROPOSED STANDARD)
Feel free to use either S/MIME (RFC2623-2634) or OpenPGP (RFC3156) on top
of 1847, depending on your personal preference in PKI trust schemes.
There is a general failure throughout the draft to distinguish between
the concepts of "authentication" (proving who the sender of an e-mail is)
and "authorization" (whether I want to accept mail from this source).
In addition, it seems to make a general assumption that the same spammers
who currently lie through their teeth about such basic things as a From:
address will magically tell the truth in this scheme. The draft would
benefit greatly from a careful re-reading, and at *each* point where the
sending system has to provide information, ask 2 questions:
1) Is this information that a spammer would feel motivated to lie about?
2) Does the protocol accept a source-provided value for the information?
A *very* basic precept in security is to not trust user-supplied data, and
this draft fails to do so in a huge number of ways.
I've not bothered thinking about scaling issues, as there are lots of basic
problems with the draft - the fact that it won't work on my laptop that only
handles 400-500 pieces of mail a day means that it's not worth asking how it
will fare on our central mail server that's seeing 200K POP3 connections an
hour, or how it will scale to the billions that Hotmail/MSN is seeing...
Now on to specifics... on page 15/16 we have:
Use a trusted connection between [10] and [20]. This can be
achieved by enforcing the use of assigned internal IPÆs,
firewall, encryption, etc. It is also recommended that the
connection does not use a clear text mechanism when possible.
This is already done by using SMTP AUTH and/or STARTTLS on port 587.
Page 20:
4. The AMDP recipient server [70] will accept envelopes that meet
its business requirements, do not violate the public mail
policy [60], and can authenticate themselves.
The first two points are a purely internal matter (business requirements
and mail policy), and RFC2821, section 4.2.3 already lists this error code:
550 Requested action not taken: mailbox unavailable
(e.g., mailbox not found, no access, or command rejected
for policy reasons)
so an SMTP server is totally within its rights to return '550 Policy rejection'
for mail that it doesn't like.
"Can authenticate themselves" is also already doable already - simply reject
connections that don't do STARTTLS with a verified certificate.
The devil is in the details - the problem here isn't authentication, it's
authorization. On the one hand, it is *certainly* doable to just say "I refuse
e-mail that I haven't previously authorized the sender". To see how broken this
is, consider that this policy would prevent your receipt of this e-mail, since
I'm fairly sure that I haven't sent you mail before.
On the other hand, simply saying "make them have a valid X.509 cert" isn't
workable either, for all the usual "whack-a-mole" reasons - unless you have
some way to make sure that spammers cannot get a cert, you can't use the
cert as a "I am not a spammer" test.
serve the mail messages. However in both instances these
servers are authenticated as MHFs in the DNS entries of
Yahoo.com.
And *OF COURSE*, the MHF for spammers-r-us.com is authenticated as such in
it's DNS. And the whole idea of a callback is broken as well - you're
introducing a whole new TCP 3-way handshake, which doesn't prove anything.
If I want to prove that a business is legitimate, I don't call the phone
number they gave me - whoever answers the phone there will say of course they
are legit. You need to call the Better Business Bureau or some similar
trusted third party and see what they say. Similarly, if I get spam from
some site, I'm certainly *not* seriously expecting that I'll contact the
server that *THEY* tell me to contact, and have that server say "Don't
accept the mail, it's spam". Again, an authentication/authorization issue.
The MHF also keeps track of the email topics also known by
threads, by maintaining an active list of threads. The
originating MHF will maintain the master copy of the thread
index. When negotiating message ids, the servers can send the
updated thread keys to the receiving server if it requires
having the thread tree which is used to reference back the
thread. This is useful to reduce the size of a message if it
is a thread so you do not need to send the original message
back and forth. A thread is also related to the to the
classification scheme, where the originator or sender can
classify the message.
This makes the very broken assumption that there exists one server that
sees all of the thread *and is authoritative* for that thread. If your
mail had also been posted to ietf-822 and that list was on a different server,
and then different subthreads which were sometimes cross-posted and sometimes
not, would horribly confuse the concept of "thread".
Rejected Classifications
This defines the classifications that are not accepted by the
network administrator i.e. a government agency, or an elementary
school do not want to accept any mail from marketing firms. And
any MHF contacting them with such messages will be reported back
to the external incident reporting service [120].
Hello? www.mail-abuse.org? I'd like to report a spammer....
There's already a *LOT* of organizations that provide blacklists of
sites - if you can't name at least 6, you haven't been in the anti-spam
business long. You probably want to think very long and hard about the
reasons for the existence of *so many* blacklists, and why there is still
spam increasing even with the existence of said lists....
Government - This means that the emails generated are mainly
official in nature, and mass mailing is not expected from these.
Educational - This means that the emails generated are mainly
educational, and not to be confused with messages from .edu
domains. A university may be classified as a business if its
emails are to prospective students, while domains or MHFÆs used to
server students email, can set this key to "Personal" or "Bulk"
depending on the volume of messages generated.
Hmm... that puts vt.edu in quite the pickle. We're a university, but we're
also an agency of the Commonwealth of Virginia. For some things, we can also
be considered a $740M/year company...
And I would like to point out that such things as "government official mass
mailings" *do* exist (want to guess how the Governor gets information to as
many people as possible about things like changes to the pension plan? ;)
If "educational" isn't "mail from .edus", you're opening yourself up to a *BIG*
abuse hole - a spammer can just claim "he was just educating the public about
a new offer".
And there isn't much here to prevent a spammer from lying about the nature of
their "personal, not used for spam" domain, is there?
This is the sub category of mail types and it is defined by the
user. It lets the final recipient know what type of message it
is, and it used for informational purposes only, since there is no
way to guarantee that the field is used correctly. However it is
"No way to guarantee". Exactly - that's the problem here.
--
Valdis Kletnieks
Computer Systems Senior Engineer
Virginia Tech
pgpw3tklqMzzE.pgp
Description: PGP signature