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
bad.
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
there..
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).
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
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:
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
about?
In my opinion that spammer will lie at every chance they get :) so the
less
areas are left to lie about the less confusing info we receive..
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...
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
here
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
mail
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
requirements
and mail policy), and RFC2821, section 4.2.3 already lists this error
code:
Yes and no. What is proposed here that a truley public mail policy is to
be
used. something similar to robots.txt where any person wishing to email
the domain must query the server first. This reduce wasted time and
resources
for both sender and receipient, this is also not available today. I can
live
with today's rules but should not we tell the person trying to email us
publicly
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
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.
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
with
AMDP envelopes (not the content of eth mesage) is much more acceptable
than
dealing with the storage requierment for the actual message. The sender
MUST
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"
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.
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
report
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
sources.
Domain A can not deny that mail is not from his domain, since the design
gaurantees
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
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.
yes I agree see above, the three way handshake is just one of many
conditions
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
removed
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
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".
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? www.mail-abuse.org? 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
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....
:) I do know a few. Working on ayna.com we had unforunatly been on few
lists
and I had to go and explain what happen to be taken off the list.
Spammers
put a return address of ayna.com, and how can I explain to few thousand
angry
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
there..
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
fit.
_______________________________________________________________
Ayna.com the Arabic web starts right here.