ietf-asrg
[Top] [All Lists]

[Asrg] [ASRG] SMTP pull anyone?

2009-08-17 05:53:54
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.

Bill,

Today's model is no different from what i have suggested in that they deploy
costly anti-spam

solutions, which utilise probably 10 fold resource than what this solution
will use. By allowing the system to cut most of the spam through a simple
pull mechanism, compares very well against today's anti-spam software model,
which not all can afford.

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.

Actually SPF only validate the legitimacy of the sender IP and domain
relation and i mentioned SPF as just a example. And if the large senders
cannot implement something as simple as a TXT record for SPF (leave alone
DKIM), then probably they do no care about spam. SPF or DKIM are only
effective when deployed by all the domains that send mails.

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?

What i mean is in order to prevent a system from getting overwhelmed, by
anonymous submission, if for say domain1.com server knows the next 10
message ID that will be sent by domain2.com, then it can confidently reject
those message submission attempts that does not have any mails in this range
(ofcourse this logic holds only if domain2.com is going to send those 10
message IDs domain1.com only)

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.

I guess we are expecting a magic solution that will stop all the spam in a
single go and would not require us from changing our system continuosly. But
unfortunately, every system has flaws and has to be corrected one step at a
time, this i believe is the evolution.
I have done my best to detail how this system applies in various steps of a
mail communication, may be i can work on a pictorial representation, if
someone else requires it as well.


Regards,
Ravi
_______________________________________________
Asrg mailing list
Asrg(_at_)irtf(_dot_)org
http://www.irtf.org/mailman/listinfo/asrg