Subject: [Asrg] [ASRG] SMTP pull anyone?

From: Ravi shankar <[email-masked]>
Date: Mon, 17 Aug 2009 15:23:36 +0530

>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

---

From: John Levine <[email-masked]>
Date: 17 Aug 2009 13:03:57 -0000

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

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

---

From: Rich Kulawiec <[email-masked]>
Date: Mon, 17 Aug 2009 10:44:50 -0400

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

---

From: Douglas Otis <[email-masked]>
Date: Mon, 17 Aug 2009 09:24:32 -0700

> 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

---

From: Rich Kulawiec <[email-masked]>
Date: Mon, 17 Aug 2009 22:09:52 -0400

> 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. "[email-masked]".  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

---

From: Bill Cole <[email-masked]>
Date: Tue, 18 Aug 2009 12:49:33 -0400

Ravi shankar wrote, On 8/17/09 5:53 AM:
>  >mail as legitimate or illegitimate by various standards of legitimacy,
> and a
>
> 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.

>  >that the envelope sender address of a message is not forged. It is
> very rare
>
> 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.

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

>  >In order to bring anything truly new and useful to controlling email
> spam, a
>
> 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.

---

From: "Chris Lewis" <[email-masked]>
Date: Tue, 18 Aug 2009 11:17:32 -0600

Bill Cole wrote:

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

---

From: Dave CROCKER <[email-masked]>
Date: Tue, 18 Aug 2009 11:00:36 -0700

> Precisely - in fact, it increases the work the receiver has to do, 

+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

---

From: Douglas Otis <[email-masked]>
Date: Tue, 18 Aug 2009 13:45:46 -0700

> Precisely - in fact, it increases the work the receiver has to do,

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

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

> 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

---

From: "Chris Lewis" <[email-masked]>
Date: Wed, 19 Aug 2009 00:16:05 -0600

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

---

From: Jeff Macdonald <[email-masked]>
Date: Wed, 26 Aug 2009 12:06:58 -0400

>        and increasing resource cost:

<snip very detailed list>

Rich, does ipv6 change any of this?

-- 
Jeff Macdonald
Ayer, MA

---

From: John Levine <[email-masked]>
Date: 26 Aug 2009 18:06:01 -0000

>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

---

From: Douglas Otis <[email-masked]>
Date: Wed, 26 Aug 2009 12:29:54 -0700

>> Rich, does ipv6 change any of this?
[]
> will become much more important to recognize mail from people you know

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

---

From: Daniel Feenberg <[email-masked]>
Date: Wed, 26 Aug 2009 17:22:35 -0400 (EDT)

> I'm not Rich, but the open question at this point is how effective

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

> _______________________________________________
> Asrg mailing list
> [email-masked]
> http://www.irtf.org/mailman/listinfo/asrg
>

---

From: Graeme Fowler <[email-masked]>
Date: Wed, 26 Aug 2009 23:17:19 +0100

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

> 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

---

From: Rich Kulawiec <[email-masked]>
Date: Wed, 26 Aug 2009 18:21:05 -0400

> I'm not Rich, but the open question at this point is how effective

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

---

From: Jeff Macdonald <[email-masked]>
Date: Wed, 26 Aug 2009 23:17:28 -0400

> 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

---

From: Steve Atkins <[email-masked]>
Date: Wed, 26 Aug 2009 20:30:17 -0700

On Aug 26, 2009, at 2:22 PM, Daniel Feenberg wrote:

> 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

---

From: "Chris Lewis" <[email-masked]>
Date: Wed, 26 Aug 2009 23:48:12 -0400

> more effective on IPv6 than v4 for the obvious NAT / dynamic  

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.

---

From: Alessandro Vesely <[email-masked]>
Date: Thu, 27 Aug 2009 12:50:44 +0400

John Levine wrote:
> 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.

---

From: Tim Chown <[email-masked]>
Date: Thu, 27 Aug 2009 10:26:33 +0100

> 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

---

From: Rich Kulawiec <[email-masked]>
Date: Thu, 27 Aug 2009 07:29:17 -0400

> 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

---

From: Douglas Otis <[email-masked]>
Date: Thu, 27 Aug 2009 16:23:23 -0700

> 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

---

From: Daniel Feenberg <[email-masked]>
Date: Fri, 28 Aug 2009 07:38:54 -0400 (EDT)

Tim Chown wrote:

>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

---

From: Douglas Otis <[email-masked]>
Date: Fri, 28 Aug 2009 10:36:08 -0700

On 8/28/09 4:38 AM, Daniel Feenberg wrote:

Daniel,

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

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.

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

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

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