----- Original Message -----
From: "Zhenhai Duan" <duan(_at_)cs(_dot_)fsu(_dot_)edu>
To: "Tony Finch" <dot(_at_)dotat(_dot_)at>
Cc: "Kartik Gopalan" <kartik(_dot_)gopalan(_at_)gmail(_dot_)com>;
<ietf-smtp(_at_)imc(_dot_)org>;
<asrg(_at_)ietf(_dot_)org>; <lemonade(_at_)ietf(_dot_)org>; "Yingfei Dong"
<yingfei(_at_)hawaii(_dot_)edu>
Sent: Tuesday, May 10, 2005 4:03 PM
Subject: Re: Re: draft-duan-smtp-receiver-driven-00.txt
Our comparison above was to IM2000. Indeed the current SMTP servers
know how to handle senders that are denied (blacklisted), or allowed
(whitelisted). A message that falls in neither class is currently
subject to the content filters to decide if it is a spam message or
not. To put it another way, the current SMTP does not have an explicit
concept of unclassified senders.
Hmmm, I believe we do. It is called "anonymous" clients.
Currently, the BCP is to only allow anonymous "unclassified" senders to send
local or hosted final destination mail. Otherwise we have what is generally
called a "open relay." The basic rule of thumb is Anonymous Senders
(unclassified) can only send local mail and Authorized Senders (classified)
can relay mail.
Since some form of authentication is required for relaying mail, by far,
the troublesome issue of problematic transactions is due to the unclassified
nature of anonymous senders.
For our SMTP server logic, the default is email
authentication/authorization only kicks in for anonymous "unclassified"
clients.
The one we are aware of that supports
the similar concept is Greylisting, which defines unclassified sources
as new triplets that are not in the whitelist and blacklist yet.
Call Back Verifiers (CBV) are also in place which is essentially a
"SMTP-based challenge" to validate the reverse path, dynamically and only
the spot, based on the theory that a Bounce Address must be correct as soon
as it is provided. This helps eliminates NXDOMAIN and bad email domains
transactions. Rejection are 45x based so a good system that is
"temporarily" down will try again. Bad Systems do not.
Don't forget SPF (and her clones) - which is currently arguably the
"pseudo-standard" and/or direction many in the industry is heading and/or
exploring. SPF attempts to validate the transaction IP address against the
email and/or client domains using a DNS based domain published policy.
So indeed there is quite an effort going on to address the "unclassified"
anonymous senders.
Mind you, a recent concern is addressing the abused ISP user who will
authenticate to bypass any smtp checking. I believe most believe the
only non-intrusive effective way to address this is by using a message
posting pattern recognition technique.
However, as other people on this list have pointed out already,
spammers haven't yet adapted to this scheme because it hasn't impacted
their bottomline. This would happen once greylisting becomes
widespread.
Greylisting, in my perspective , is mostly used at the low end of the
spectrum. Although there are more of the low end server than the comparably
less large systems as a whole, off hand, I don't know of any major or larger
ISP or corporation that uses GreyListing, and for good reason. These
delayed challenge response systems is problematic in the business market.
For example, I don't want to put a barrier up to potential customers sending
sales inquiries to sales(_at_)santronics(_dot_)com(_dot_)
So I personally don't see Greylisting become mainstream. I think the
industry will look for something else first before they put up contact
barriers.
This is a good point and Kartik's email addressed your question to
some extent by mentioning that some MTA modifications are inevitable
to make them DMTP-compliant. As it is in the current draft, the sender
MTA IP address is used for the RMTA to retrieve the complete message.
Keep in mind the idea of receiving a payload for post authentication
concepts can be very problematic. Microsoft's SenderID proposal has this
problem and the key reason why we won't directly implement it into the SMTP
server.
The idea is to not accept the payload if the transaction parameters are not
good.
By accepting the payload, you increase the effectiveness of spammer's
mailing list. They could care less of the payload is eventually accepted or
not. If a spammer can show thier customers that a good bit of their
addresses are making it pass the door (SMTP level) then this tends to
increase the marketability of the mailing list. The secondary acceptance
of the message itself by the user is just the cat's meow.
We made this choice because of security concerns and also for the
simplicity of the RMTA. It is possible that instead of relying on RMTA
to record the SMTA IP address, we can do a DNS MX lookup of sender
email address to get the MTA IP address at the sender side. However,
this indeed means that if sender side uses different MTA servers for
incoming and outgoing messages, they need to be in sync about state of
outgoing message queue (for example, shared file systems). In the long
run, its a tradeoff worth making.
Personally, I doubt that it is. I think the redesign requirements do not
give you
any more value than what is currently available and in place using a
"current
SMTP compliant" model to address the anonymous (unclassified) mail sender.
You need to keep in mind that based on industry empirical data, 60-80% of
all anonymous transactions are problematic and a majority of these can be
addressed at the SMTP level. Most of the concern I believe the cogs have
with the proposed methods is overhead and redundancy related.
At the very least, I think the only real bonus in the proposal is Message ID
tracking.
If MSID is used to track messages, then call back or other similar systems
can use this information to obtain originality.
If every system was required to keep a table of MSID, then we have
trackability (technical) and accountability (legal).
Please note, as a SMTP vendor, I am all for a great idea. But if massive
changes is going to be required, then it needs to make sense across the
board. In my view, SMTP is a great protocol which has the elements to
eliminate the "forging" aspect of the transaction. SPAM Analysis and
content analysis, to me, is out of the scope of SMTP. It can be hooked in
today already. But 2822 and 2821 are two different things. Its like the
US postal mail man. He could care less what he is delivering to you. But
you as a receiver might have place some level of scrutiny at the mail man
before you even look at the content he is handing over to you. Does he
have a uniform? Does he have a badge? Does he look like a bum? Do you
recognize him? Does he have a permit to deliver mail? Or is he just a
friendly neighbor who is routing mail to you?
So unless the mind set can be changed to begin looking at stronger
client/server negotiations of the SMTP transactions, and more important
adding an enforcement level of compliance, big changes like you suggest, I
don't see having much value.
--
Hector Santos, Santronics Software, Inc.
http://www.santronics.com