[Top] [All Lists]

Re: Introduction and query

2003-02-10 00:07:59
Hi Valdis,

I welcome your comment, and thank you for being the first to bring great
points to the table for discussion. I will definetly look into the
refences pointed out in your message. 

Before I answer some of the points presented here I would like to make
the distinction about the major differences between the two appraches of
mail delivery, and I hope as I make these points the readers will start
seeing the differences that may not be apparent from initial glance of
the document.

In SMTP you actually have to receive the message in its entirety before
you can apply any of spam filters, unless you have a filter on email.
Most of spam messages hurt in the pocket becuase you have to receive
them before you figure if they are welcome or not. You have to store
them, process them, and figure out what to do next.. Sometimes I use the
term "band-aid the problem," and what I meant is that the damage is done
by the spammer once you receive the message to decide if it is good or

In AMDP you do not have to do that at all, becuase the sender MUST keep
the mail message on their OWN server, and send you an envelope
describing its contents. Then they have to autheticate themselves so you
know that a mail message is actually residing where the spammer/or non
spammer says. Most of the spam today uses fake FROM, so this will stop
this kind of abuse. Today you can send mail to anyone and claim to be
from yahoo, ietf or any one else. In AMDP you can not do that, I agree
that we can do this in extenstions of SMTP and I do not really mind
where it is implemeted as long as it is done somewhere.. The point is to
start clean, use the good points of SMTP but put something better out

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
extensions, or isn't a generally bad idea engineering or security

A whole class of things addressed here (authentication and
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
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
and "authorization" (whether I want to accept mail from this source). 
Ok I should take than into consideraion when wording changes to
document. The 
MIME standards will all stand true as today within AMDP, it is the
process of
deliverying mail that is the subject of the proposal, not the
encryption, or packaging
since many system rely on these mail formats.

In addition, it seems to make a general assumption that the same
who currently lie through their teeth about such basic things as a
address will magically tell the truth in this scheme. The draft would 
benefit greatly from a careful re-reading, and at *each* point where
sending system has to provide information, ask 2 questions: 

AMDP will enforce that mail received has to be from an explicitly
assigned host
by the domain admin. This is not available in SMTP anyone can do it, and
if they
do lie it will not accept the mail. They can make domains for that
purpose, which is 
fine becuase at this point the source of spam is known, which can not be
traced at 
all in smtp. (there are other measures in the document to make it
wrothless for 
a spammer to do what they do today)

1) Is this information that a spammer would feel motivated to lie
In my opinion that spammer will lie at every chance they get :) so the
areas are left to lie about the less confusing info we receive..

2) Does the protocol accept a source-provided value for the

A *very* basic precept in security is to not trust user-supplied data,
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
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
It depends on which piece of the puzzle we are talking about.

The idea behind it is in the details of the protocol. If you have a
small site
then you can set your public mail policy in such a way that you will not
be flooded
by mesages, and you will only handle what you can. In SMTP your server
crashes and there is nothing you can do to stop the spam unless you pull
the plug :(

Small sites will also have to use the services of the post office, since
they will 
offer MHF services on behalf of your domain. It will be like shipping a
package today
if you can not handle it yourself, then give it to experts.

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. 
Sure why not. there is not need to reinvent the wheel. the difference
is that 20 is not used to email the outside world but to enforce
outgoing mail 
rules. you can not do this in SMTP today. You can not enforce outgoing
size, language, etc.. that is what [20] is there for..

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
and mail policy), and RFC2821, section 4.2.3 already lists this error
Yes and no. What is proposed here that a truley public mail policy is to
used. something similar to robots.txt where any person wishing to email
the domain must query the server first. This reduce wasted time and
for both sender and receipient, this is also not available today. I can
with today's rules but should not we tell the person trying to email us
hey! we will not take mail from you, unless...??

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
for mail that it doesn't like. 

"Can authenticate themselves" is also already doable already - simply
connections that don't do STARTTLS with a verified certificate. 

The devil is in the details - the problem here isn't authentication,
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. 
It is not about rejecting mail. If you are dealing with a domain dealing
with few
million messages a day. The space and computing power needed to deal
AMDP envelopes (not the content of eth mesage) is much more acceptable
dealing with the storage requierment for the actual message. The sender
keep the message on their server until it is picked up by the end user

On the other hand, simply saying "make them have a valid X.509 cert"
workable either, for all the usual "whack-a-mole" reasons - unless you
some way to make sure that spammers cannot get a cert, you can't use
cert as a "I am not a spammer" test. 
The certification is just one of the methods to use to autheticate
domains in good
standing. I did not cover this in the document, since I thought it will
be too much
for a first draft, however the general idea goes like this.

Once you know that an email is coming from domain A and no one else,
then we 
can go to a third party (that is paid by domain A to be their
certificate manager) and 
check if they are within the category they claim to be. So if domain A
claims to be 
XY category and ends up being ZZ using some smart filters, then we can
the abuse to the manager of the certificate and they update the category
based on 
feedback not only from me, but based on reports received from other AMDP
Domain A can not deny that mail is not from his domain, since the design
that the host must be explicitly authroized to mail. All mail from A to
other AMDP 
servers will autmoatically be converted to the new classification since
the third party
job is to provide the realtime classification of the domain.

One option that I looked at is to charge small fees for incoming mail
messages, so even 
if a spammer fakes everything, by imposing a pay-per-message model, you
can control 
the flow of messages. 

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
If I want to prove that a business is legitimate, I don't call the
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
some site, I'm certainly *not* seriously expecting that I'll contact
server that *THEY* tell me to contact, and have that server say "Don't
accept the mail, it's spam". Again, an authentication/authorization
yes I agree see above, the three way handshake is just one of many
that play together to close the wholes available in SMTP.

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 is open to discussion, if it can not be implemented than it can be
nothing written in the proposed document is written in stone :) I agree
with you
we will find things that are already there that can be integrated..

This makes the very broken assumption that there exists one server
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
and then different subthreads which were sometimes cross-posted and
not, would horribly confuse the concept of "thread". 
I agree again, this may be difficuly to implement (at the least the
thread synching)
but the idea here is to create an automatic schema that allows certain
email classification
to be autmoatically saved to tape in antipicpation to some ruling by SEC
where companies
must backup all communication relating to certain business practices. 

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.... 
Sure the [120] is an open end, i.e. AMDP will have to define an API that
is used by any external
incident reporting service, not like today, you have to draft an email,
check what happened to it.
The idea is to automate the system so reports are sent and received in
real-time, so if you have
a virus in your network it will automatically alert the external
network, and other AMDP servers
will know of this before the mail admin does!!

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
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
spam increasing even with the existence of said lists.... 
:) I do know a few. Working on we had unforunatly been on few
and I had to go and explain what happen to be taken off the list.
put a return address of, and how can I explain to few thousand
people it is not us!!!

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 use

=== message truncated ===
Sorry it seems that my mail client truncated the message. We can disuss
them later, but the examples are just that, they can be anything you
want, and they can flexible to meet tha needs of real business out

However the discussion of the categories is also an extensive one and
will need a group of dedicated people to figure out somtheing that would

_______________________________________________________________ the Arabic web starts right here.

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