Discussion:
SMTP pull anyone?
Ravi shankar
2009-08-16 11:20:39 UTC
Permalink
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.

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.

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.

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.

Note: I have gone trough IM2000 and other similar discussions in the
archive. Just thought this version of C/R is worth getting discussed.

Regards,
Ravi
Bill Cole
2009-08-16 18:14:00 UTC
Permalink
Post by Ravi shankar
Hi,
Me and my buddy had a interesting discussion, which i thought could put
across the geeks here.
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.
Post by Ravi shankar
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.
Post by Ravi shankar
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?
Post by Ravi shankar
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.
Post by Ravi shankar
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?
Ian Eiloart
2009-08-17 10:05:44 UTC
Permalink
Post by Bill Cole
Post by Ravi shankar
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.
SPF deployment has grown rapidly from 5% of 2,000,000 sampled domains to
17% over the past three years, apparently including most USA banks. About
half of spf publishing domains, including some large senders like facebook,
use "-all" records. Apart from anything else "-all" on its own is a good
way of saying "this isn't an email domain", and it's probably a good idea
to publish it for every A record that doesn't point to a mail server.

Furthermore, some large recipients like gmail use these records to help
assign reputation to senders. Forwarded email is likely already suffering
from deliverability problems when the sender address is not rewritten (at
least in cases like forwarding facebook mail to gmail, for example), and
these problems will continue to get worse, not better as SPF deployment
increases, and as records are increasingly respected.

People who want to offer a reliable forwarding service to their users
already need to be thinking about rewriting sender addresses.

It might take a few years, but I'm convinced that we'll look back on SPF
deployment in the same was that we look back on the campaign against open
relays some years ago.
--
Ian Eiloart
IT Services, University of Sussex
01273-873148 x3148
For new support requests, see http://www.sussex.ac.uk/its/help/
mathew
2009-08-16 18:38:12 UTC
Permalink
Post by Ravi shankar
Me and my buddy had a interesting discussion, which i thought could
put across the geeks here.
[... pull e-mail description...]

I wrote up something very similar, and as noted, there was IM2000.

At this point, the consensus on this list as far as I can determine is
"Nothing will work, and if you think otherwise go implement it and
prove us wrong". So I'd suggest digging out an ANSI C compiler as your
only productive next step.


mathew
--
<URL:http://www.pobox.com/~meta/>
Dave CROCKER
2009-08-16 18:45:50 UTC
Permalink
Post by Ravi shankar
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.
<http://v3.espacenet.com/textdoc?DB=EPODOC&IDX=US6192407>
--
Dave Crocker
Brandenburg InternetWorking
bbiw.net
John Levine
2009-08-16 22:29:44 UTC
Permalink
Post by Dave CROCKER
Post by Ravi shankar
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.
US6192407
Ah, right, the famous Tumbleweed patent. Here's a better link
with a readable version.

http://www.google.com/patents?vid=USPAT6192407

This patent covers the idea of putting a message on a web server and
sending the recipient a URL to retrieve the message. Tumbleweed
enforces it very aggressively. See the list of suits in their
Wikipedia page.

Were it not for the patent, I expect we'd have a lot of institutions
setting up per-user password protected RSS or Atom feeds with
statements and other messages, and sending you mail telling you to
check your feed when there's something new.

R's,
John
Michael Thomas
2009-08-17 16:34:27 UTC
Permalink
I don't see how push or pull fundamentally changes the spam
equation in any case. The problem wrt spam is the any-any nature
of who you receive communication from, not who initiates the
connection.

I can create a walled garden trivially with smtp just be rejecting
connections from people not on my whitelist. Likewise, anything that
is promiscuous with who it receives from better be prepared for
mail-transmitted diseases (MTD's). That's just the nature of opening
up. So SMTP itself isn't the problem, or more specifically fretting
about SMTP is nipping around the edges of 20 with the 80-20 rule.

Mike
Post by John Levine
Post by Dave CROCKER
Post by Ravi shankar
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.
US6192407
Ah, right, the famous Tumbleweed patent. Here's a better link
with a readable version.
http://www.google.com/patents?vid=USPAT6192407
This patent covers the idea of putting a message on a web server and
sending the recipient a URL to retrieve the message. Tumbleweed
enforces it very aggressively. See the list of suits in their
Wikipedia page.
Were it not for the patent, I expect we'd have a lot of institutions
setting up per-user password protected RSS or Atom feeds with
statements and other messages, and sending you mail telling you to
check your feed when there's something new.
R's,
John
_______________________________________________
Asrg mailing list
http://www.irtf.org/mailman/listinfo/asrg
Douglas Otis
2009-08-17 17:14:44 UTC
Permalink
Post by Michael Thomas
I don't see how push or pull fundamentally changes the spam
equation in any case. The problem wrt spam is the any-any nature
of who you receive communication from, not who initiates the
connection.
The pull concept is fairly simple. When creating a white-list, it
becomes important to identify the source of the message. Since email
uses store and forwarding, originating sources of messages can be
difficult to determine, based upon the message alone. Of course DKIM
helps with that, but it would be more ideal to shift a greater portion
of the burden toward the sender for email to continue to scale.

By exchanging only references to messages that are held on-line, the
message itself does not need to be initially exchanged. When contacted
by a specific source that has been white-listed, your MUA could fetch
the desired message from the on-line server at the same time references
have been retrieved.

When a reference has been falsified, no message can be fetched. This
would not demand cryptographic efforts by the sender, or expect receipt
of an exponentially increasing volume of junk, or tens or hundreds of
DNS transactions per domain to resolve server authorizations.

One wonders whether IMAP might be tweaked to provide an online function
rather than using traditional URIs. The problem should not be viewed as
the 80-20 rule where 80% of the problems are caused by 20% of the
sources. This should be viewed as the 99-99 rule, in today's email
environment.

-Doug
John Levine
2009-08-18 03:47:36 UTC
Permalink
I don't see how push or pull fundamentally changes the spam equation
in any case. The problem wrt spam is the any-any nature of who you
receive communication from, not who initiates the connection.
I agree. The main advantage I see to pull is bandwidth management,
since recipients can decide when and whether to retrieve mail for
users, rather than having to accept it all just in case someone wants
to read it.

The disadvantage is that it requires that senders and receivers all be
connected to the same network all the time, which is a lot closer to
true now than it was in the 1980s, but still a long way from
universally true.

R's,
John
Dave CROCKER
2009-08-18 14:24:25 UTC
Permalink
Post by John Levine
I agree. The main advantage I see to pull is bandwidth management,
...
Post by John Levine
The disadvantage is that it requires that senders and receivers all be
connected to the same network all the time,
The disadvantages are more substantial. This is a very high overhead model, in
terms of hassling the recipient and in terms of transactions costs.

d/
--
Dave Crocker
Brandenburg InternetWorking
bbiw.net
Bart Schaefer
2009-08-18 08:01:36 UTC
Permalink
Post by John Levine
The disadvantage is that it requires that senders and receivers all
be connected to the same network all the time, which is a lot closer
to true now than it was in the 1980s, but still a long way from
universally true.
I'm not a proponent of the pull model, but it seems to me this could
be overcome if each receiver in a store-and-forward sequence were
able to inform its immediate upstream when it is not able to perform
the pull.

E.g., transmit the "pull handle" as far as possible, then have the
last relay that is capable of doing so, issue the pull request.

This could probably even be done with one new SMTP verb plus ETRN.
E.g. DATA FROM:<message-id> where the domain part of the message-id
must resolve to the host that will cough up the message. If the
receiver responds 50z or 455, the sender must do the pull. If the
receiver responds 354, sender sends dot, and eventually some receiver
connects to <message-id-domain> and issues ETRN #<message-id-local>.

All sorts of security implications to be worked out, Tumbleweed
problems aside.
Alessandro Vesely
2009-08-18 13:40:20 UTC
Permalink
Post by Michael Thomas
I can create a walled garden trivially with smtp just be rejecting
connections from people not on my whitelist. Likewise, anything that
is promiscuous with who it receives from better be prepared for
mail-transmitted diseases (MTD's). That's just the nature of opening
up. So SMTP itself isn't the problem, or more specifically fretting
about SMTP is nipping around the edges of 20 with the 80-20 rule.
I don't think "opening up" is bound to have a unique nature. A
protocol might provide for ways to open up _and_ allow
traceability, responsibility, and accountability. Such features
are implicit in walled gardens. Explicating them requires a more
thorough analysis of the relevant conventions and rules, at an
abstraction level such that its outcome can be globally
accepted. Much of the required "political" work is already
available as privacy recommendations --later than SMTP. It is
possible to tweak SMTP so as to comply with that. While that
would not "eliminate spam", it would permit to manage it
cleanly, properly, and without sacrificing reliability.
Ravi shankar
2009-08-17 09:53:36 UTC
Permalink
Post by Bill Cole
DNS is used *as a medium* for various applications that are used to
identify
Post by Bill Cole
mail as legitimate or illegitimate by various standards of legitimacy, and
a
Post by Bill Cole
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.
Post by Bill Cole
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
Post by Bill Cole
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.
Post by Bill Cole
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.
Post by Bill Cole
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)
Post by Bill Cole
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
Post by Bill Cole
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
John Levine
2009-08-17 13:03:57 UTC
Permalink
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
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.
Rich Kulawiec
2009-08-17 14:44:50 UTC
Permalink
Post by Ravi shankar
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
Douglas Otis
2009-08-17 16:24:32 UTC
Permalink
Post by Rich Kulawiec
Post by Ravi shankar
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
Rich Kulawiec
2009-08-18 02:09:52 UTC
Permalink
Post by Douglas Otis
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. "***@boss.com". 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
Jeff Macdonald
2009-08-26 16:06:58 UTC
Permalink
Post by Douglas Otis
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
<snip very detailed list>

Rich, does ipv6 change any of this?
--
Jeff Macdonald
Ayer, MA
John Levine
2009-08-26 18:06:01 UTC
Permalink
Post by Jeff Macdonald
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
Douglas Otis
2009-08-26 19:29:54 UTC
Permalink
Post by John Levine
Post by Jeff Macdonald
Rich, does ipv6 change any of this?
[]
Post by John Levine
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
Daniel Feenberg
2009-08-26 21:22:35 UTC
Permalink
Post by John Levine
Post by Jeff Macdonald
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
Post by John Levine
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
http://www.irtf.org/mailman/listinfo/asrg
Graeme Fowler
2009-08-26 22:17:19 UTC
Permalink
Apologies if this comes over in an inflammatory or tediously weak way,
but...
Post by Daniel Feenberg
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
Steve Atkins
2009-08-27 03:30:17 UTC
Permalink
Post by Daniel Feenberg
Post by John Levine
Post by Jeff Macdonald
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 see this asserted a lot, but I don't really see much in the way of
plausible arguments to back it up.

If anything, some blacklist techniques are likely to be easier and
more effective on IPv6 than v4 for the obvious NAT / dynamic
assignment reasons.

Cheers,
Steve
Douglas Otis
2009-08-27 23:23:23 UTC
Permalink
Post by Steve Atkins
I see this asserted a lot, but I don't really see much in the way of
plausible arguments to back it up.
If anything, some blacklist techniques are likely to be easier and
more effective on IPv6 than v4 for the obvious NAT / dynamic
assignment reasons.
Frankly, I don't think anything that earth shattering will occur, even
if ipv6 takes over completely.
Undoubtably some techniques will work better, some about the same, and
some won't work worth squat - they'll either evolve to work better, fade
into meaninglessness, or just outright die.
It's not as if it hasn't happened before. See much use of open relay
DNSBLs anymore? Thought not.
Treating /64 (the network of an IPv6 addresses) as having the same
reputation is destine for support issues when exceptions are needed for
various legitimate services.

When establishing an IPv6 block list, once exceptions are made,
retaining evidence for each of these exceptions removes any semblance of
there being an upper limit on the number of IP addresses logged. After
all, bad actors will start wearing large snowshoes in exception ranges.

For IPv6 addresses to become first-class citizens of the email
community, listing those that should be accepted rather those blocked
represents perhaps the only scalable solution while using similar tools.
Using DKIM messages to request inclusion of a new domain can also
assist in validating the servers.

Alternative solutions such as accessing a link returned to the domain
might be used as well. Nevertheless, DKIM should help reduce the
validation steps needed, and could help prioritize and expedite
inclusions requests. Knowing the domain rather than just an IP address
also allows more extensive correlations with prior abuses.

-Doug
Daniel Feenberg
2009-08-28 11:38:54 UTC
Permalink
Post by Tim Chown
Based on our stats from June, we received an average of 158,000 messages
per day over IPv4 transport, of which 81% were deemed spam, while we
received 438 (yes, 438!) messages via per day IPv6, of which 32% were
spam. So even for us, v6 is less than 1% of all received mail.
The relevant percentage would be the spam percentage coming from hosts
that have no IPv4 address. The quality of dual-stacked hosts is not
really germane to the question of whether IPv6 only hosts will ever exist.

I don't doubt that many MTAs will accept IPv6 mail. What I dispute is the
liklihood of anyone running a legitimate Internet MTA that accepts mail
from an IPv6 only host. My reasoning is that such a host would have
limited connectivity. There are two reasons for this. (1) Many MTA
operators will lag in the adoption of IPv6 due to general lack of
interest, ability or funds, so an IPv6 only MTA will have no access to
many MTAs, much worse even than MTAs operating at dial-up addresses
currently have. (2) Anyone operating an MTA on IPv6 will have to do
without the single most effective anti-spam technique we have, the DNSBL.
This will cause many operators with the resources to add IPv6 to hesitate
to do so.

Given either of these two reasons, few or no MTAs will run IPv6 only,
which obviates the need for IPv6 entirely.

Of course, some operators can do without DNSBLs, and they can
easily operate dual-stack. There is no practical way they can drop IPv4,
nor will they ever be able to do so.

So, how much mail came from IPv6-only hosts? And what was the percentage
of spam?

Daniel Feenberg
Douglas Otis
2009-08-28 17:36:08 UTC
Permalink
On 8/28/09 4:38 AM, Daniel Feenberg wrote:

Daniel,
Post by Daniel Feenberg
I don't doubt that many MTAs will accept IPv6 mail. What I dispute is
the liklihood of anyone running a legitimate Internet MTA that accepts
mail from an IPv6 only host. My reasoning is that such a host would have
limited connectivity. There are two reasons for this. (1) Many MTA
operators will lag in the adoption of IPv6 due to general lack of
interest, ability or funds, so an IPv6 only MTA will have no access to
many MTAs, much worse even than MTAs operating at dial-up addresses
currently have. (2) Anyone operating an MTA on IPv6 will have to do
without the single most effective anti-spam technique we have, the
DNSBL. This will cause many operators with the resources to add IPv6 to
hesitate to do so.
Given either of these two reasons, few or no MTAs will run IPv6 only,
which obviates the need for IPv6 entirely.
One of the significant changes we needed to make in our service when
becoming more popular in Asia's Pacific Rim, was to provide setting that
precluded other regions by default. This desire might not be
xenophobic, but based rationale interests. When large portions of a
country's connectivity is IPv6, having preferences for IPv6 seems
logical. The question you might consider would be whether those in IPv6
predominate regions even wish to accept IPv4 connections from areas
blighted with spam in languages foreign.
Post by Daniel Feenberg
Of course, some operators can do without DNSBLs, and they can easily
operate dual-stack. There is no practical way they can drop IPv4, nor
will they ever be able to do so.
Be a bit cautious about considering this a general statement.
Post by Daniel Feenberg
So, how much mail came from IPv6-only hosts? And what was the percentage
of spam?
This type of measure will never uncover the amount of region specific
exclusions. You might be surprised to find IPv4 is not always king.

-Doug

Tim Chown
2009-08-27 09:26:33 UTC
Permalink
Post by Daniel Feenberg
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.
I think this assumption has some problems, particularly in the area of
IPv6 transition.

If one assumes that RFC3974 is still generally valid, and sites use both
A and AAAA records for MXes (as we do here), then such sites may receive
email via IPv4 or IPv6, depending on the preference of the sending MTA.
And that's the important thing - that MTA if sendmail (for example)
defaults to trying IPv6 first, so you won't just receive IPv6 SMTP
connections by being IPv6 only, but also from any sender who, probably
like you, is dual-stack.

We choose to run MTAs dual-stack so we can accept mail (internally or
externally) from IPv4-only, IPv6-only or of course dual-stack nodes.

I think if you reject IPv6 SMTP, even if 'just' from strangers, you
make transition harder - you either don't turn on v6, or if you do you
prefer v4 over v6. Neither helps transition.

Based on our stats from June, we received an average of 158,000 messages
per day over IPv4 transport, of which 81% were deemed spam, while we
received 438 (yes, 438!) messages via per day IPv6, of which 32% were spam.
So even for us, v6 is less than 1% of all received mail.

The spam was largely from dual-stack mail list servers, not from random
clients/hosts. But it's interesting to look at specific connections -
non list spam tends to come from autoconfigured v6 addresses (implying
desktops) while 'good' mail comes from apparently manually configured
IPv6 addresses (because v6 admins know to not use autoconf addresses on
their servers).

One day I will convert the experience of 3+ years of running a dual-stack
MTA in production to a draft, and analyse the (at least) year's worth of
data on v6 spam sources that we have :)

Tim
Rich Kulawiec
2009-08-26 22:21:05 UTC
Permalink
Post by John Levine
Post by Jeff Macdonald
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.
What John said.

Point blocks already have their issues, for example (a) hosts using
dynamic addressing can hop around within a network allocation and
(b) spammers can try to use snowshoe techniques to tread lightly
enough to evade them. And they can be unwieldly. I think all of
this is likely to get worse with IPv6. I rather suspect that this
will lead to mechanisms using entire network blocks -- some of which
we already have. (For example, we have MTAs that understand blacklists
in CIDR format.)

At least some of the other measures should continue working, though,
as they're independent of IPv4-IPv6. But I think while they may be
helpful, they're not going to be enough.

I don't see much help coming from SPF or DKIM or whatever: most of the
spam that makes it past my setup is correctly marked with one of these.
(<cough> Hotmail, Yahoo) I expect this will get much worse as spammers
begin to leverage the full power of the botnets they're operating.

---Rsk
Jeff Macdonald
2009-08-27 03:17:28 UTC
Permalink
Post by Rich Kulawiec
Post by John Levine
Post by Jeff Macdonald
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.
What John said.
Point blocks already have their issues, for example (a) hosts using
dynamic addressing can hop around within a network allocation and
(b) spammers can try to use snowshoe techniques to tread lightly
enough to evade them.  And they can be unwieldly.  I think all of
this is likely to get worse with IPv6.  I rather suspect that this
will lead to mechanisms using entire network blocks -- some of which
we already have.  (For example, we have MTAs that understand blacklists
in CIDR format.)
At least some of the other measures should continue working, though,
as they're independent of IPv4-IPv6.  But I think while they may be
helpful, they're not going to be enough.
I don't see much help coming from SPF or DKIM or whatever: most of the
spam that makes it past my setup is correctly marked with one of these.
(<cough> Hotmail, Yahoo)  I expect this will get much worse as spammers
begin to leverage the full power of the botnets they're operating.
So, if one were willing to accept that there will be valid IPv6 MTA
based connections, and the practicality of using IPv4 methods is no
longer feasible, then your list would be composed of only SMTP
envelope and body checks?
--
Jeff Macdonald
Ayer, MA
Rich Kulawiec
2009-08-27 11:29:17 UTC
Permalink
Post by Jeff Macdonald
So, if one were willing to accept that there will be valid IPv6 MTA
based connections, and the practicality of using IPv4 methods is no
longer feasible, then your list would be composed of only SMTP
envelope and body checks?
Hmmm. At the moment, it sure looks that way. Happily (at the moment)
those methods do a very good job: roughly 85% of total spam rejected
is rejected by those means before any IPv4 methods are used. But I
have to guess that this percentage will decline and that I'm going to
need to revisit/revise this.

---Rsk
Alessandro Vesely
2009-08-27 08:50:44 UTC
Permalink
Post by John Levine
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.)
Very well stated! I think we may say that, for any practical
concern, tracking IP addresses won't have clear advantages over
tracking registered domain names.

Rick's very detailed list provides many good hints. However,
sooner or later somebody should state some clear instructions
for running an MTA. I mean something that a company, an
association, or even a household can easily set up and maintain,
rather than an art/craft requiring arcane esoteric skills. In
particular, tracking registered domain names allows to keep
non-DNS settings unchanged through a change of connection
provider(s), which seems to me a worthwhile simplification.
Bill Cole
2009-08-18 16:49:33 UTC
Permalink
Post by Bill Cole
Post by Bill Cole
DNS is used *as a medium* for various applications that are used to
identify
Post by Bill Cole
mail as legitimate or illegitimate by various standards of legitimacy,
and a
Post by Bill Cole
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
Post by Bill Cole
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
Post by Bill Cole
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.
Post by Bill Cole
Post by Bill Cole
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
Post by Bill Cole
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.
Post by Bill Cole
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.
Post by Bill Cole
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.
Post by Bill Cole
Post by Bill Cole
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.
Post by Bill Cole
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.
Post by Bill Cole
Post by Bill Cole
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
Post by Bill Cole
new idea has to either attack spam in a way that existing tactics
don't, do
Post by Bill Cole
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.
Post by Bill Cole
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.
Post by Bill Cole
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.
Chris Lewis
2009-08-18 17:17:32 UTC
Permalink
Post by Bill Cole
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.
Dave CROCKER
2009-08-18 18:00:36 UTC
Permalink
Post by Chris Lewis
Post by Bill Cole
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
Douglas Otis
2009-08-18 20:45:46 UTC
Permalink
Post by Chris Lewis
Post by Bill Cole
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.
Post by Chris Lewis
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.
Post by Chris Lewis
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
Chris Lewis
2009-08-19 06:16:05 UTC
Permalink
Post by Douglas Otis
Post by Chris Lewis
Post by Bill Cole
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.
John Levine
2009-08-18 03:38:01 UTC
Permalink
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
Steve Atkins
2009-08-18 03:43:13 UTC
Permalink
Post by 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.
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
Alessandro Vesely
2009-08-18 12:52:27 UTC
Permalink
Post by Steve Atkins
Post by 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.
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.
Post by Steve Atkins
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.
Douglas Otis
2009-08-18 17:10:23 UTC
Permalink
Post by Steve Atkins
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
Loading...