[ASRG] SMTP pull anyone?

[Ravi shankar-15]

>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@...
http://www.irtf.org/mailman/listinfo/asrg

[John Levine-3]

> 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.

I gather that you are proposing a system in which mail from a particular
domain can only be offered from servers that are somehow authorized by
or related to that domain.  If so, that is a huge change to the SMTP
store-and-forward model.

The predecessor to SMTP was a hack layered on FTP which only worked if
the sender and recipient systems were both online at the same time
and could talk directly to each other.  SMTP store-and-forward
was a big advance over that a lot of real useful mail systems depend
on being able to deliver mail in multiple stages.

If your idea is that mail from foo.com can only come from a foo.com
server or something like that, you might want to explain how your
proposal differs from RSS, and particularly from the model in the
Tumbleweed patent.

R's,
John

PS:

>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.

No we are not, and I have to say that's not a very useful line of argument.
_______________________________________________
Asrg mailing list
Asrg@...
http://www.irtf.org/mailman/listinfo/asrg

[Rich Kulawiec]

On Mon, Aug 17, 2009 at 03:23:36PM +0530, Ravi shankar wrote:
> 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.

If they are costly, and if they use so many resources, then they're not
very good solutions.  It's not difficult at all to construct very cheap,
very efficient anti-spam solutions which exhibit good performance
characteristics (that is: low FP, low FN, no backscatter, no spamming,
no special MUA/MTA software needed, etc.)

The fact that some (many?) people choose not to avail themselves of these
methods is unfortunate, but doesn't invalidate the methods.

---Rsk


_______________________________________________
Asrg mailing list
Asrg@...
http://www.irtf.org/mailman/listinfo/asrg

[Douglas Otis]

On 8/17/09 7:44 AM, Rich Kulawiec wrote:

> On Mon, Aug 17, 2009 at 03:23:36PM +0530, Ravi shankar wrote:
>> 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.
>
> If they are costly, and if they use so many resources, then they're not
> very good solutions.  It's not difficult at all to construct very cheap,
> very efficient anti-spam solutions which exhibit good performance
> characteristics (that is: low FP, low FN, no backscatter, no spamming,
> no special MUA/MTA software needed, etc.)
>
> The fact that some (many?) people choose not to avail themselves of these
> methods is unfortunate, but doesn't invalidate the methods.

Rich,

Could you provide a brief outline regarding what constitutes an
efficient anti-spam solution?

-Doug
_______________________________________________
Asrg mailing list
Asrg@...
http://www.irtf.org/mailman/listinfo/asrg

[Ravi shankar-15]

@John Levine,

 

The model is like a simple C/R involving Message ID of a mail. The sending domain provides the Message ID and allows computational time for the receiving domain and then query the sending domain to send the message.

 

Apparently i was not aware of the tumbleweed patent, in which case, Tumbleweed, can claim this model if implemented as a infringement or complete violation.

 

Regards,

Ravi

_______________________________________________
Asrg mailing list
Asrg@...
http://www.irtf.org/mailman/listinfo/asrg

[Rich Kulawiec]

On Mon, Aug 17, 2009 at 09:24:32AM -0700, Douglas Otis wrote:
> Could you provide a brief outline regarding what constitutes an  
> efficient anti-spam solution?

Sure.  In brief (really brief!) and in (rough) order of application
        and increasing resource cost:

Spamhaus DROP list on perimeter routers/firewalls
Consider IDP list on perimeter routers/firewalls
Use firewall rulesets per-country, see ipdeny.com *or* if possible,
        use default-deny and grant access per-country
Use multiline SMTP greeting (defeats some zombies)
Use "greetpause" or equivalent (defeats some zombies)
Enforce DNS/rDNS existence/consistency checks on
        hostname, MX records and HELO parameter;
        defer/reject as appropriate
Blacklist known virus/ratware senders, e.g. "big@...".  Faster
        than running through an AV check
Permanently blacklist known phisher domains.  Even if acquired by legit
        companies will never be used.
Consider blacklisting spammer-infested/useless TLDs (e.g., .info, .mobi)
        with whitelisting as needed, if needed
Permanently blacklist known spammer domains (e.g. Joe Wein's list)
Permanently blacklist any "snowshoe" domain/domain group on sight
Blacklist any "snowshoe" network range on sight
Use enemieslist or other similar rDNS-based blocks on end-user/dynamic names
Use Spamhaus Zen DNSBL
Use other DNSBLs/RHSBLs as appropriate
Throttle connections with excessive attempts/deliveries
        to nonexistent users/etc.

Obviously, the choice of which ones, in which order, with which
configuration, depends on mail system administrator knowledge of local
mail patterns.  Everyone should analyze their own logs to gain that
knowledge.  And some of these are no-brainers no matter what those
patterns are, e.g., DROP list, DNS/rDNS checks, Spamhaus Zen, etc.
And I've probably omitted some by doing this off the top of my head.
On a Monday. ;-)

---Rsk
_______________________________________________
Asrg mailing list
Asrg@...
http://www.irtf.org/mailman/listinfo/asrg

[John Levine-3]

>The model is like a simple C/R involving Message ID of a mail. The
>sending domain provides the Message ID and allows computational time
>for the receiving domain and then query the sending domain to send
>the message.

This model has been proposed many, many, times before.  I suppose we should
make a page for it in the ASRG wiki of anti-spam techniques even though it's
more of a mail system redesign than an anti-spam measure.

R's,
John
_______________________________________________
Asrg mailing list
Asrg@...
http://www.irtf.org/mailman/listinfo/asrg

[Steve Atkins]

On Aug 17, 2009, at 8:38 PM, John Levine wrote:

>> The model is like a simple C/R involving Message ID of a mail. The
>> sending domain provides the Message ID and allows computational time
>> for the receiving domain and then query the sending domain to send
>> the message.
>
> This model has been proposed many, many, times before.  I suppose we  
> should
> make a page for it in the ASRG wiki of anti-spam techniques even  
> though it's
> more of a mail system redesign than an anti-spam measure.

If you do, mention RFC 2017.

Cheers,
   Steve

_______________________________________________
Asrg mailing list
Asrg@...
http://www.irtf.org/mailman/listinfo/asrg

[Ale2008]

Steve Atkins wrote:

> On Aug 17, 2009, at 8:38 PM, John Levine wrote:
>
>>> The model is like a simple C/R involving Message ID of a mail. The
>>> sending domain provides the Message ID and allows computational time
>>> for the receiving domain and then query the sending domain to send
>>> the message.
>>
>> This model has been proposed many, many, times before.  I suppose we should
>> make a page for it in the ASRG wiki of anti-spam techniques even though it's
>> more of a mail system redesign than an anti-spam measure.

Agreed; however, I'm out of office this week, and will consider
doing this only when I'll be back. (As a new entry in
http://wiki.asrg.sp.am/wiki/Taxonomy_of_anti-spam_techniques#SMTP_techniques 
I suppose).

IMHO, this model --this instance of it-- stems from the common
qui pro quo generated by speaking of clients (or servers) as if
they were hosts, rather than processes: Most spam comes from
clients, I want to eliminate it, hence I will only pull mail
from servers.

> If you do, mention RFC 2017.

Good point. External-Body resembles "SMTP pull", except for
implying that the content should be retrieved by the MUA.

RFC 2111's mid URLs could be used to retrieve a message sent by
SMTP (or stored via IMAP) if access by Message-ID were provided.

In order to infringe the Tumbleweed patent, AFAICS, one
additionally has to automate checking the log file, as an
alternative to positive DSNs for the externally stored content.
_______________________________________________
Asrg mailing list
Asrg@...
http://www.irtf.org/mailman/listinfo/asrg

[Bill Cole-2]

Ravi shankar wrote, On 8/17/09 5:53 AM:

>
>
>  >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.

I don't see how this reduces the effort required on the receiving side in
comparison to currently common practices. I do see how it increases
receiving system effort compared to currently common practices. I suspect
that you don't understand those practices, so I'll explain at length...

It is very common for mail servers to apply multiple threshold criteria
(often utilizing DNS) before the DATA command in a SMTP session to decide
how to respond to the earlier commands, often making rejection decisions
very early. SPF and the most common type of DNSBL can be checked that way
and often are, along with rules like requiring the sender domain to have a
valid MX or A record, shunning clients that use idiosyncratically invalid
HELO names, etc. This does not require message data analysis, as it is done
before the message data is offered. After receiving a RCPT command, the
receiver knows the IP address of the sending client, the name it used for
itself in the HELO or EHLO command, the envelope sender address, one or more
recipient addresses, and the reject/accept results for any previously named
recipients. In some cases where extensions to SMTP are used, it may also
know some message and authentication metadata. It is quite normal for a mail
server to use those facts and derivative facts (like the existence and
content of DNS records related to them) to decide how to respond to that
RCPT command.

For many mail systems, anti-spam measures done before the DATA command using
metadata safely reject a large majority of spam (often a large majority of
all email) and whitelist a smaller stream of messages. This sidesteps
high-cost approaches that parse message data. For example, from the last
10,000 connections to my own very small mail server, only 873 messages were
passed to the part of my spam control system that examines the message data
and 35 messages were cleared around that filtering. Obviously I can't get a
perfect measurement for accuracy since I can't be sure that every error will
be noticed and brought to my attention, but it has been many months and
millions of messages since the last time I know that system to have rejected
a legitimate message ahead of the data filters and it hasn't protected any
spam from data filtering in the 5 years that I've been doing it. That
performance is similar to what I've seen in the larger mail systems that
I've managed for others.

The use of metadata rules (i.e. using envelope and session parameters and
their derivatives) to reduce the flow of mail into message data filters is
not a new or rare strategy, but rather is an evolutionary remnant of the
earliest spam control tactics. For many years, spam exclusion was almost
exclusively done before the DATA phase of SMTP because it worked well enough
and because filtering based on message data was more resource-intensive than
it could justify with results. To this day, well-run mail systems whose
operators are concerned about the resource demands of spam control use the
information available early in the SMTP transaction to decide whether to
allow the sender to 'push' the message itself.

The 'pull' model you have described does not specify any way in which it can
improve on the pre-data filtering that is already being done, but it does
add a burden to both sides of legitimate transactions: keeping track of
message offers that are pending a decision to pull and an actual pull
attempt. In order to justify that added burden (in addition to the huge
development and deployment costs) you would need to explain how your pull
model facilitates better filtering than what sites do now. Sparing systems
from message data filtering isn't enough, unless you have some case for your
model doing that consistently and sustainably better than current tactics
that operate during the SMTP session.

>  >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.

SPF is specified as applying to the whole envelope sender. Explicit records
using the %l macro are rare, but many domains assure that the hosts they
affirm in SPF are using correct local parts in sender addresses. That is
what would be expected with normal MTA software and configurations that
could be affirmed in SPF.

> 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.

I understand that it is easy and tempting to be dismissive about the lack of
care among large senders, but it is self-defeating when trying to devise and
evangelize a new spam control mechanism.

It is worth noting that Microsoft (as Hotmail) has been the most important
actor in getting SPF records deployed by others, even though Hotmail systems
are chronic spam sources and their inbound mail systems do not use SPF
records in anything like a normal way.

 > SPF or DKIM are
> only effective when deployed by all the domains that send mails.

That is a ridiculously false statement. I have to assume that we are having
a problem of differing idioms of English, or else I would think you a fool.

>  > 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)

Okay, so you are redefining "Message ID" as a new identifier defined by each
MTA for each message that it handles, rather than as something related to
the Message-ID mail header.

That concept is interesting, but it is not consistent with how mail systems
work today. It brings into question whether you have a useful understanding
of the range of ways that people use email and the range of ways that mail
servers handle mail. The practices that would have to end in order to enable
this facet of your idea include those which forced SPF into its arcane
complexity and those which constrain its strength and deployability today.

>  >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.

Not at all, and that is part of why I am skeptical about your suggestion. It
would be a radically new way of handling email, to a degree that it would
not really make sense to define it as an extension to SMTP.

> But unfortunately, every system has flaws and has to be
> corrected one step at a time, this i believe is the evolution.

Gradual evolutionary steps have to provide a real hope of some incremental
benefit to early adopters without doing them immediate harm. Even if you had
a fully detailed model for how this would work and had a deployable way to
integrate it today into existing mail systems, you would need to assure that
it would be harmless to offer now (i.e. no rejection of legitimate mail from
non-users of the new system) and that it could provide some benefit for both
senders and receivers who adopt it before it becomes widely deployed. As
described, it increases the difficulty of handling mail for both sides and
offers neither side any concrete benefits.


> 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.

If this is what you consider "detail" then you have a major obstacle to
being taken seriously. Drawing pictures wouldn't be a step forward. Defining
a transaction protocol would be, but I wouldn't suggest you do that until
you identify concrete ways that your model offers benefits that existing
common practices cannot offer.
_______________________________________________
Asrg mailing list
Asrg@...
http://www.irtf.org/mailman/listinfo/asrg

[Douglas Otis]

On 8/17/09 8:43 PM, Steve Atkins wrote:

>
> On Aug 17, 2009, at 8:38 PM, John Levine wrote:
>
>>> The model is like a simple C/R involving Message ID of a mail.
>>> The sending domain provides the Message ID and allows
>>> computational time for the receiving domain and then query the
>>> sending domain to send the message.
>>
>> This model has been proposed many, many, times before. I suppose we
>> should make a page for it in the ASRG wiki of anti-spam techniques
>> even though it's more of a mail system redesign than an anti-spam
>> measure.
>
> If you do, mention RFC 2017.

Good point since this RFC was adopted in October 1996 and patent
5,790,790 was filed October 24, 1996 by Jeffry C. Smith of Menlo Park,
and Jean-Christophe Bandini, of Cupertino. But patent 6,192,407
describes "private URLS" or PURLS and was filed April 1997.


XAM offers an 80 byte reference that can be made "public" while still
offer security that does not involve the moving parts found in the '97
patent.

-Doug
_______________________________________________
Asrg mailing list
Asrg@...
http://www.irtf.org/mailman/listinfo/asrg

[Chris Lewis-2]

Bill Cole wrote:

> I don't see how this reduces the effort required on the receiving side in
> comparison to currently common practices.

Precisely - in fact, it increases the work the receiver has to do,
probably substantially.

Consider: the offer/callback approach is identical to SMTP up to the
DATA keyword.

The "offer" would have to have more-or-less the same information as the
pre-DATA SMTP information in normal SMTP.  A SMTP server can just as
easily reject on that data pre-DATA, as to "choose not to do" the call
back.  So, up to this point, the offer/callback approach doesn't do any
less work than normal SMTP.

Then offer/callback actually has to call back and retrieve the message.
  You also have to build in mechanisms to make sure that someone _else_
isn't doing the retrieval.

Then, if you do any DATA filtering, _both_ approaches have to do similar
levels of work.

In other words, the offer/callback approach only causes you to expend
more work actually implementing the callback _itself_, plus checking it
for validity.
_______________________________________________
Asrg mailing list
Asrg@...
http://www.irtf.org/mailman/listinfo/asrg

[Dave Crocker-2]

Chris Lewis wrote:
> Bill Cole wrote:
>
>> I don't see how this reduces the effort required on the receiving side in
>> comparison to currently common practices.
>
> Precisely - in fact, it increases the work the receiver has to do,
> probably substantially.


+1.

When discussing different protocol models, folks should be required to explain a
collection of relatively obvious cost/benefit differences, such as:

1. Latency/Delay

2. Transaction (Round-trip) exchange count

3. Robustness/fragility

4. Administration

5. Privacy

6. Authenticity/Spoofing

...


For the SMTP push model (and ignoring the possible pull last-hop):

1. Low latency
2. A bit too chatty, but pipelining largely fixed this
3. History demonstrates high robustness
4. Low administration (only DNS MX)
5. Privacy is theoretically non-existent
6. Authenticity is demonstrably horrible

d/

d/
--

   Dave Crocker
   Brandenburg InternetWorking
   bbiw.net
_______________________________________________
Asrg mailing list
Asrg@...
http://www.irtf.org/mailman/listinfo/asrg

[Douglas Otis]

On 8/18/09 10:17 AM, Chris Lewis wrote:
> Bill Cole wrote:
>
>> I don't see how this reduces the effort required on the receiving side in
>> comparison to currently common practices.
>
> Precisely - in fact, it increases the work the receiver has to do,
> probably substantially.

As accepted IP addresses are reduced, there will be increased abuse of
existing services, that were likely exposed through information gleaned
from compromised computers.  This will eventually move the problem to
the point where the IP address of the client offers fewer clues about a
message source.  Without some simply means to identify undesired
messages, the sheer volume of undesired email will provide a growing
burden.  Especially when content filtering must be deployed.  It is hard
to imagine a more resource intensive strategy.

> Consider: the offer/callback approach is identical to SMTP up to the
> DATA keyword.

Not if MUA or specialized MDAs gather the messages marked as desired. A
selection based upon the offers should reduce the overhead considerably.

> The "offer" would have to have more-or-less the same information as the
> pre-DATA SMTP information in normal SMTP.

No. Unlike that of an SMTP exchange, when reference information is not
valid, the reference does not work.  This removes the validation steps.

-Doug
_______________________________________________
Asrg mailing list
Asrg@...
http://www.irtf.org/mailman/listinfo/asrg

[Chris Lewis-2]

Douglas Otis wrote:
> On 8/18/09 10:17 AM, Chris Lewis wrote:
>> Bill Cole wrote:
>>
>>> I don't see how this reduces the effort required on the receiving side in
>>> comparison to currently common practices.
>> Precisely - in fact, it increases the work the receiver has to do,
>> probably substantially.

>> Consider: the offer/callback approach is identical to SMTP up to the
>> DATA keyword.

> Not if MUA or specialized MDAs gather the messages marked as desired. A
> selection based upon the offers should reduce the overhead considerably.

This does not provide any new mechanisms for deciding what is, in fact,
wanted.

Step back.  The "hard part" of this proposal is deciding what email is
desired.  The proposal makes no suggestions on something "new" that
could be used to do this.  As it stands, it's simply a more convoluted
and expensive version of SMTP.

What does "pull" provide that existing "push" does not in terms of
improved filtering?  Until and unless you can answer that, it's moot.

Does it provide a innovative way of deciding what email is desired?  No.

That you don't transfer the DATA if the email is undesired?  Given that
the vast majority of spam is well under 10K in size, this pales in
comparison to the complexity and network loading of actually performing
the pull.

Certainly, you can extend the push to include additional stuff.  Like
DKIM or something different.  But that's just as easily done/possible in
push, and already is.

Letting the MUA fill up with offers, and forcing the user to to decide
what's wanted has the same problems as junk folders.  The legit email
gets lost in the noise.

In fact, junk folders are "pull".  How well do they work?  Not well.
_______________________________________________
Asrg mailing list
Asrg@...
http://www.irtf.org/mailman/listinfo/asrg

[Jeff Macdonald-4]

On Mon, Aug 17, 2009 at 10:09 PM, Rich Kulawiec<rsk@...> wrote:
> On Mon, Aug 17, 2009 at 09:24:32AM -0700, Douglas Otis wrote:
>> Could you provide a brief outline regarding what constitutes an
>> efficient anti-spam solution?
>
> Sure.  In brief (really brief!) and in (rough) order of application
>        and increasing resource cost:

<snip very detailed list>

Rich, does ipv6 change any of this?


--
Jeff Macdonald
Ayer, MA
_______________________________________________
Asrg mailing list
Asrg@...
http://www.irtf.org/mailman/listinfo/asrg

[John Levine-3]

>Rich, does ipv6 change any of this?

I'm not Rich, but the open question at this point is how effective
DNSBLs will be on IPv6.

A DNSBL that blocks a single IP at a time, like the CBL and XBL, would
be unworkable.  A typical v6 setup allocates a /64 to each host which
allows various sorts of clever self-configuration, but also means the
host can easily use a different IP address for every connection it
ever makes. (At one address per millisecond, it would take 500 million
years to run through a /64.)  DNSBLs can and do list ranges, and an
obvious change would be to make the finest listed granularity be a
/64, but we really have no idea how the vast number of v6 addresses
will be handed out, and whether it will be practical to create
listings that cover all of the available addresses for a particular
host without also listing a lot of its neighbors.

This suggests that whitelisting techniques (most likely based on DKIM)
will become much more important to recognize mail from people you know
are credible.

R's,
John
_______________________________________________
Asrg mailing list
Asrg@...
http://www.irtf.org/mailman/listinfo/asrg

[Douglas Otis]

On 8/26/09 11:06 AM, John Levine wrote:
>> Rich, does ipv6 change any of this?
[]
> This suggests that whitelisting techniques (most likely based on DKIM)
> will become much more important to recognize mail from people you know
> are credible.

Agreed. The transition will be from blocking bad, to accepting known
good.  One might expect efforts being made to vet new domains or IP
addresses.

-Doug
_______________________________________________
Asrg mailing list
Asrg@...
http://www.irtf.org/mailman/listinfo/asrg

[Daniel Feenberg]

On Wed, 26 Aug 2009, John Levine wrote:

>> Rich, does ipv6 change any of this?
>
> I'm not Rich, but the open question at this point is how effective
> DNSBLs will be on IPv6.

I think it unlikely that an IPv6 only MTA will ever have acceptance even
as wide as, for instance, MTAs with "pool" or "dial-up" in their RDNS.
IPv6 only MTAs will be refused by many MTAs. There are simply too many
IPv6 addresses to blacklist bad hats, and blacklisting /48s would be a
very broad brush. The advantage of IPv4 is that the number of addresses is
finite, and legitimate holders of addresses are loath to waste them.

I understand that many IPv6 capable MTAs exist, but I expect they do all
or nearly all of their external traffic via IPv4. I don't mean a general
condemdantion of IPv6, I am only saying that SMTP traffic from strangers
on IPv6 is not likely to be worthwhile.

Daniel Feenberg

>
> A DNSBL that blocks a single IP at a time, like the CBL and XBL, would
> be unworkable.  A typical v6 setup allocates a /64 to each host which
> allows various sorts of clever self-configuration, but also means the
> host can easily use a different IP address for every connection it
> ever makes. (At one address per millisecond, it would take 500 million
> years to run through a /64.)  DNSBLs can and do list ranges, and an
> obvious change would be to make the finest listed granularity be a
> /64, but we really have no idea how the vast number of v6 addresses
> will be handed out, and whether it will be practical to create
> listings that cover all of the available addresses for a particular
> host without also listing a lot of its neighbors.
>
> This suggests that whitelisting techniques (most likely based on DKIM)
> will become much more important to recognize mail from people you know
> are credible.
>
> R's,
> John
> _______________________________________________
> Asrg mailing list
> Asrg@...
> http://www.irtf.org/mailman/listinfo/asrg
>

_______________________________________________
Asrg mailing list
Asrg@...
http://www.irtf.org/mailman/listinfo/asrg

Apologies if this comes over in an inflammatory or tediously weak way,
but...

On Wed, 2009-08-26 at 17:22 -0400, Daniel Feenberg wrote:
> I understand that many IPv6 capable MTAs exist, but I expect they do all
> or nearly all of their external traffic via IPv4. I don't mean a general
> condemdantion of IPv6, I am only saying that SMTP traffic from strangers
> on IPv6 is not likely to be worthwhile.

This is different from IPv4 SMTP traffic from strangers how, exactly?
The vast majority of previously unseen connections handled by MTAs under
my direct control right now using v4 only are "not likely to be
worthwhile". The fact that there are several powers of 2 (well, many)
more hosts in the v6 world makes no difference apart from a scaling
factor.

Imagine if I ran a hypothetical organisation which used network
intelligence gathered from previous SMTP sessions to determine how to
handle a connection from a previously unseen host - it wouldn't matter a
jot if those connections came from a v4 or a v6 host. The only common
factor is that they were previously unseen (ie a "stranger").

Well run organisations will fix the address (as they do now) of their
outbound MTAs, and therefore allow intelligence to build up over time
about their usage and "goodness quotient". If anyone's crazy enough to
float the outbound IP around, even inside a v4 /24, then they should
expect their reputation to stay on the side of "low". If they do it
inside a v6 /64, they're really crazy.

Graeme

_______________________________________________
Asrg mailing list
Asrg@...
http://www.irtf.org/mailman/listinfo/asrg