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.net
> mnt-by: MAINT-MAIL2WORLD
> changed: wkim <at> mail2world.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.
RSS Feed