Ravi shankar wrote, On 8/16/09 7:20 AM:
Hi,
Me and my buddy had a interesting discussion, which i thought could put
across the geeks here.
It goes something like this:
SMTP is currently a push protocol and is initiated by the the sender, no
controlling that fact.
But it is possible to overcome the relay problems, IP spoofing and
domain impersonation etc,
by making the servers pull the mails.
1. Sending server contacts the destination and proovides the Message ID
and sender details(and other details) and disconnects the session.
2. The receiving server queues it up and looks up the messages one by
one using DNS to determine their legitimacy.
DNS itself provides no mechanism for determining the legitimacy of email.
DNS is used *as a medium* for various applications that are used to identify
mail as legitimate or illegitimate by various standards of legitimacy, and a
major reason for its use in those applications is to make it feasible for
mail systems to do the validation synchronously during the SMTP session. By
using a lightweight, distributed, cached database, mail systems are spared
from deferring a message, queuing its validation, remembering the results,
and waiting for the sender to offer it in an identical way again. You are
suggesting that receivers should take on all the heavyweight management but
retain using DNS for something unspecified. It makes no sense.
3. If the IP that contacted is legitimate(can be verified by say SPF?),
it contacts the sender and provides the message ID with other details.
The *most* that SPF can provide towards showing "legitimacy" is to confirm
that the envelope sender address of a message is not forged. It is very rare
for large senders of any sort to deploy records that can do that strongly.
There is nothing about SPF that directly attacks spamming. It could in
theory be used to attack sender forgery, but the collateral damage has
proven to be too great for either sending or receiving systems to actually
apply it strongly to that end. Meanwhile, a lot of spammers are sending a
lot of spam with senders that are validated to the degree that SPF can
validate anything.
4. The sending server then hands over the message.
5. To overcome DDoS attacks, the receiving server can be made to request
the next 10 or so Message IDs that it will assign to messages,
so that if a attacker tries to give those details, it will know from the
next list of message IDs that it's fake connection.
That sentence makes no sense. What did you mean to say?
6. May be by this collection of data, the IP addresses can be reported
to a RBL and blacklisted.
Please point the holes in this model, so that we might get a entirely
new insight.
Nothing you have described would add to spam control as it is currently
being done, as far as I can see. The 'model' is too vague to critique inn
detail because you aren't really providing any meaningful details.
In order to bring anything truly new and useful to controlling email spam, a
new idea has to either attack spam in a way that existing tactics don't, do
a demonstrably better job than existing tactics, or overcome the negative
aspects of existing tactics. You have identified none of those in your new
idea.
Note: I have gone trough IM2000 and other similar discussions in the
archive. Just thought this version of C/R is worth getting discussed.
As described, there's not much to discuss. It looks like it might be a
little like IM2000 (which has been a complete failure) if fleshed out, but
you haven't explained how this would differ from it, how it would integrate
with existing SMTP, or how it would offer anything significantly better than
existing mechanisms.
Right now, receivers can choose to validate the sender against SPF records
after receiving the MAIL command and reject non-validating messages at that
point, or they can wait until RCPT if they want their rejections to be more
broadly respected, or they can wait until the second phase of DATA if they
want to weight SPF results along with other filters that rely on message
data. Many sites already explicitly reject the vast majority of offered
messages in response to RCPT or earlier without requiring legitimate senders
to sit on a pile of pending offered messages that may or may not be asked
for later. You have not identified any benefits for receiving systems or
legitimate senders, so it is hard to agree that it is "worth getting
discussed" or indeed worth anything at all. Where is the added value?
_______________________________________________
Asrg mailing list
Asrg(_at_)irtf(_dot_)org
http://www.irtf.org/mailman/listinfo/asrg