Good morning Valdis :)
AMDP is about fairness and distributing the processing of a message
between the
sender and receiver. SMTP does not outline a "fair" process for
deliverying messsages.
The recipient takes the short end of the stick. The recipient has to
process, store, and deliver
the message, in AMDP I am trying to shift the store and deliver parts to
the sender,
while leaving the process, and some parts of the store/deliver in the
hands of the recpient.
In our day-to-day business you do not pay or facilitate for the sender
to send you what they
want, and SMTP we do just that. We pay for the network connectivity, and
have to be
purdened by unsolicited messages. The way we curtail this in our lives
by reversing the
process where the sender has to take care of paying for the services to
deliver (i.e. storing, and
delivering) and we just open the package. The reversed process and
imposed fees are the
best control mechanism for free-for-all spamming. It is not a magic
bullet, but it is a well
proven concept that when adapted to the mail process on the net, a
fundamental change
of how spam is handled will occur.
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.
Quite correct.. However...
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.
Notice that you still have to download the entire message to tell if
the
other end is telling the truth regarding its contents. And I've seen
enough Murkowski-compliant "Under S.1618, this message isn't spam if
it
includes a remove link" spam to not believe that spammers will tell
the
truth in the envelope. As you yourself note - a big problem is that
they
lie in the MAIL FROM - why would APMD-MAIL-CLASS contain truth?
No you do not have to download the message in its entierty yo assert
that.
There are two cases for AMDP mail to accept a message.
1. in the public policy is states what is allowed to come in based on
size limitations
if the message being read from the connection exceeds +/- some bytes the
transfer is
terminated. i.e. i can set my public policy to say
Max email size 30k which means message >= 30 will pass to be delivered
(including
content, if as we receive it the counting algorithm hits 35k, the
message is dropped)
this is the difference. We asked the mailer to be honest, if they do
not, we drop the
message. So if they want a message to pass they have to be bound by the
terms
of the public policy.
Again back to the APMD-MAIL-CLASS. I propsed three part for it
1 is the one set up by the domain admin is basically does not
telll us anyting about the type of email, instead it tells us if this
domain is managed internally a thirda party (agent), or if it is a
public
gateway like yahoo, hotmail etc..
2. the second part is set by the user, which is the spammer, but it is
status is validated and maintained through a third party. This service
will provide certain key information regarding the classification
a) the classification claimed by the sender
b) classification reported by receiveing users
c) data since inception of certificate
d)... anything else we need to validate the claims
You keep saying that spammer wil lit in their classification, and of
course
they will do that. The certificate will tell us what the have been doing
on other sites, and give statistics about the report ratio and when a
cenrtificate was issued used. there could be a statsitical honesty meter
applied to the stats coming in from AMDP server at each query which are
used in building the case for or against a domain.
Now back to the public policy. I can set up a policy such as this
a) we accept mail messages that do not exceed 30k (which is fine be
our network)
b) we will accept category DIRECT::PERSONAL for a price of $0.001
c) we will accept category *::* for a price of $0.25
d) (this is not in document but came out of our disccsuion)
there could be a section in the public policy that points out the
rates for the "honesty rating" such as
- no rating or poor one : 50 cents / message
- 2-4 rating 30 cents
- 4-6 rating 20 cents
- etc.. the better the rating the lowest, it could even have a
- 10 rating (excellent) 0 cents
What you are creating here is a mechanism that is self correcting
becuase
you are using other non-legal or tehcnical solutions to overcome the
descrepencies in the classification. The prize for the unsolicited mail
business is lower rates for better reporting of their classifications.
Also I proposed the addition of a subsription engine that is linked to
domains
that have heavy subscription made on behalf of their users, which will
provide
these businesses with email messages that want to receive messages to
them
and that will give them the lowest rates to deliver the messages.
There is also the rate (not money but time in between connections) at
which we
accept envelopes from an source is specified by the AMDP server when it
negotiates connection withe connecting server.
So in the event it is a spammer, only one message is received until
1. we can contact them (eliminates using other people's domains)
2. and payment in the event that things did not check using
3. the time lag we informed him to wait has elapsed
I want to reiterate, you will not stop spam, but you will be open in
your communication and be able to set rules. Failure to meet those
rules will drop a message, and the utlimate goal is for them to get the
message to the users, and as long as you use "post" processing
you will fail in controling the problem.
If anything, this is actually doing the spammer a favor - it means
that he
can save bandwidth. Sites that have blacklisted them won't call back
to
pick up the spam.
I do not get you comment here. You as a receipient save money too,
becuase
you did not receive or process the spam, teh spammer is loosing becuase
he did not achieve his goal of deliverying the message, and now he has
to
maintain the messages on his servers for delivery by people who want to
receive those messages.
On the other hand, sites that have blacklisted the spammer already are
free
to issue a 550 on the MAIL FROM or RCPT TO and thus skip the DATA
phase, so
you're not actually providing any benefit here.
Yes I agree, but spammer empersonate mail messages from yahoo, msn, aol,
rcn,
etc.. as a business many of these crucial domains can not be
blacklisted. Sometimes
we need a gray list :) and that is only possible with a realtime
mechanism that is part
of the mail delivery cycle that can be used free by the recpient, and
paid by the sender.
Again back to tha fairness model. As a recipient, who is beinf spammed,
I am being forced
to pay for more services, and subscribe to solutions, etc.. while the
spammers figure new
ways to scam me from more money, while they are breaking the law and my
piggy bank :)
By reversing these actions the spammer will have no other choice but
play by the rules, like
they do today in the air mail business. Yes we still receive junk mail,
but that is because the
post office sets the rates. If you really do not want to get junk mail,
just up your rates at the
domain level, and you will be left alone for others that want the junk.
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.
Actually, if you think really hard about it, you'll realize that this
doesn't
*really* stop fake FROM - all it does is make the spammer use a
throw-away
FROM address that happens to point to a server he controls.
Actually it does, since that host has to be explicitly on the outgoing
mail list
for the domain. Let us assume we have 100 servers within out network, as
a system admin i can assign 4 of them to be used for outgoing mail
handleing
i.e. MHFs. The chances of somone hacking onto other non-attended hosts
is much higher that the ones the admin controls. Also in the case of
abuse
it can be pin pointed to the specific host within the domain.
Today I get millions a message a month claiming to be from yahoo, and
domains
we do business with, and sometimes spammers use ISP so you can not block
that
ISP since you block everyone on that host. The AMDP model will allow teh
ISP
to set the host in question to be an MHF for his customer, and emails
outgoing
carrying a different FROM are corrected in [20] or ignored by the AMDP.
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.
It's more than just wording - it's a way of thinking. It's even
possible
to conceive and design authorization systems that don't involve any
actual
authentication at all. In this class fall proposals such as the "I
don't
care who you are, but if you send me e-mail you first have to perform
such-and-such complex computation that will chew several seconds of
CPU - this
won't matter to any legitimate one-off mail, but will matter to a
spammer".
We use this technique today in one of the products we use, where it
slows down the
spammer incrementaly, but still does not work. Many proffesional
spammers will have
a whole C bock and use them randomly to overcome settings made based on
host
Another example of anonymous authorization would be a rate-limiting
system,
where a mail server would say "I don't care WHO you are, you're only
allowed X
msgs/hour per /24 of source address space without prior arrangement" -
this is
already implemented in some systems, and deals nicely with the
"one-off
anonymous personal mail" problem while drastically limiting what a
spammer can
do.
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.
No - they merely can't use an existing domain. All this forces is that
the
spammer also has to get a DNS entry updated at the same time he buys
his
network connectivity.
Which is fine, but his category listing and "honesty" ratings are also
low, so they will
have to pay higher rates for mail delivery.
And if an ISP will sell bandwidth, they will likely sell DNS on the
same
whack-a-mole contract.
Which is also fine, becuase the MHF is where the money is going to be
for an ISP.
not is DNS.
They can make domains for that purpose, which
becuase at this point the source of spam is known, which can not be
traced at
all in smtp.
Umm.. It's traceable.
:) Yes this message is traceable because I am using a reputable company
and it is
not trying to hide who they are. I have seen verey interesting "fake"
SMTP conversations
in headers that go nowhere.
- One time IP, used to post the millions of messages and then goes
offline. In AMDP the domai has to be within the outgoing mail scheme of
the domain, and must stay online so we retrieve the message. Spweing out
a million message gonly sends out a million envelopes, not the messages.
if they want to make some cash they will need to stay online to server
those messages.
- If it is a hijacked MHF once notifed the admin can drop the message
from queue, and the damage is controled at his end.
Received: from npsmtp02la.mail2world.com (mw27.mail2world.com
[66.28.189.27])
by zidane.cc.vt.edu (Mirapoint Messaging Server MOS 3.3.2-CR) with
ESMTP id
BAS07392; Mon, 10 Feb 2003 02:07:59 -0500 (EST)
Interesting that your mailserver said 'npsmtp02la' but the PTR says
'mw27'.
Reverse DNS for the 66.28.189/24 is provided by cogentco.com, and the
IP address
block is owned by:
route: 66.28.189.0/24
descr: Mail2World Network
origin: AS26254
remarks: this is non-portable space, no exceptions
notify: wkim(_at_)mail2world(_dot_)net
mnt-by: MAINT-MAIL2WORLD
changed: wkim(_at_)mail2world(_dot_)net 20030110
source: VERIO
I'm too lazy to go poke a BGP looking-glass to see who AS26254 is
getting
transit from, but I'd start by asking Verio. ;)
A bigger problem here is that although open SMTP relays are fast
becoming
rarer (I've seen one reliable statistic that open SMTP relays have
fallen from
60% down to about 1% of the problem), there are signs that spammers
are
starting to abuse open proxy servers (many older HTTP proxies would
quite
happily accept 'CONNECT destination.com 25').
I disagree about these figures, Most of the mail I receive today uses
fake host
name, fake mail froms, open relays, fresh relays setup by the spammers
all
over the world. They use cheap ISP accounts in brazil, russia, south
africa,
middle east, canada, japan, korea, etc..
Put in place a public policy that is clear, make it easy for spammers to
spam
you on certain topics, within your computing power. Make it pricey to
email
you unsolicited mail, and you got yourself a good start.. SMTP does not
do that, and believe me if we can add these functinalities in SMTP I
will be the
first one to say let us go for it. It is not about the name, or the
packaging is
about giving domain admins control. There is no way ion SMTP that I can
manage
my domain, people often use it in spam, and there is nothing I can do
about it..
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..
Given the number of ISPs that currently block outbound port 25, this
seems
to be an "already done". All you need is a firewall that blocks
outbound
SYN packets on port 25 from everything from the mail server, and
filtering
software on the mail server. Given the number of e-mail a day I
receive with
silly "This e-mail is proprietary" banners, I have to assume that most
sites
who wish to do this already know how to do so.
You are relying on a third party to do the blocking here. Why should it
not be part
of the design?? not everyone has a firwall, and if someone want to go
around than
they can.
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.
Nothing here that ORBS and MAPS haven't been doing for years already.
ORBS and MAPS only check the host, and do not give you stats that can be
used in
between. I agree that there service can be upgraded to support a more
sophistcated
report.
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.
You missed the point - if you don't trust the spammer to tell the
truth
about "this is not spam" when he contacts you, why do you expect a
truthful
answer when you spend the extra effort to contact a server *the
spammer runs*?
I asked this to myself. In SMTP the message goes one way, regardless if
the
message is good or bad, however in most cases spam over shadows the good
mail. By doing the extra handshake i achieve the following.
1. I am forcing the sender to be online to tell me that indeed they sent
me a message
2. I am asking the sender to have that message ready for later pickup
If they do not do that, teh message is not delivered, so you are making
changes on the
other side. Spammers now have to invest in a system that can serve those
message.
Also now they can truley know which message was read, and by whom, and
concetrate
on creating a business geared on the users, and not random mailings to
no end..
Thanks in adance for your feedback..
Adonis
_______________________________________________________________
Ayna.com the Arabic web starts right here.