[Top] [All Lists]

Re: Introduction and query

2003-02-09 22:52:25
On Sun, 09 Feb 2003 20:21:42 PST, Adonis El Fakih 
<adonis(_at_)aynacorp(_dot_)com>  said:

I have submitted an Internet draft 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

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 

And *OF COURSE*, the MHF for 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?  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 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

Attachment: pgpw3tklqMzzE.pgp
Description: PGP signature

<Prev in Thread] Current Thread [Next in Thread>