Subject: [Asrg] article: port 25 blocking

From: Gadi Evron <[email-masked]>
Date: Tue, 12 Apr 2005 08:38:10 +0400

Larry has been asking a ton of questions of people online, and
participating in professional discussions on the subject, on other
lists. Here is the result of the information he gathered:

http://www.eweek.com/article2/0,1759,1784276,00.asp

	Gadi.

_______________________________________________
Asrg mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/asrg

---

From: "George Ou" <[email-masked]>
Date: Mon, 11 Apr 2005 23:37:05 -0700

Blocking port 25 harms a lot of legitimate uses.  Why not do the following
to deal with the issue as a whole.

*  Start banning all non-SPF compliant domains within a certain deadline
which would effectively make port 25 blocking moot.
*  Then we deal with the problem of ISPs who don't implement SMTP AUTH and
who won't implement some reasonable rate limiting schemes.
*  Then start requiring some sort of official registration or bonding of
domains who bulk send (based on Distributed Checksum Clearinghouse
measurements) so that we can either easily track you down for prosecution or
we confiscate the bond for any kind of abuses from an SPF abusive domain.

These steps would seem to me a lot more effective and cause a lot less
collateral damage.  As the owner of a few small personal domains and someone
who uses outbound 25 for legitimate SMTP relay, I'd much rather you force me
to put in a few SPF records than blocking my outbound port 25 access.  We're
essentially talking about the same thing here only from different sides of
the problem.  Do we create an ACL (Access Control List) that denies all
non-SMTP servers of the world or do we create an ACL that permits all
legitimate SMTP servers of the world?  It would seem to me that the latter
is a much smaller database and much easier to implement than the former.

George Ou

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Gadi
Evron
Sent: Monday, April 11, 2005 9:38 PM
To: [email-masked]'
Subject: [Asrg] article: port 25 blocking

Larry has been asking a ton of questions of people online, and participating
in professional discussions on the subject, on other lists. Here is the
result of the information he gathered:

	Gadi.

---

From: James Lick <[email-masked]>
Date: Tue, 12 Apr 2005 15:41:54 +0800

>to deal with the issue as a whole.

Blocking open relays harmed a lot of legitimate uses.  In fact, quite a 
lot of the complaints about port 25 blocking today sounds awfully 
similiar to the complaints about blocking/closing open relays seven 
years ago.  But it still happened, because the legitimate use of open 
relays was vastly outweighed by the abuse of it.  I would argue that 
unblocked port 25 on consumer level accounts has a similiar ratio of 
abuse versus legitimate use that open relays did.  Those who had 
legitimate use of open relays were able to find alternatives.  Those who 
legitimately use outbound port 25 access have alternatives already which 
include smtp auth, ssh tunneling, VPN, configuring your MTA to use your 
ISP's mail server as outbound relay, asking your ISP for an exemption to 
blocking, or simply using a premium ISP which offers static IP and 
allows servers. 

>As the owner of a few small personal domains and someone
>to put in a few SPF records than blocking my outbound port 25 access.
>  
>

If you actually read the article, his suggestion would completely 
accomodate your situation.  He proposes that port 25 be blocked by 
default on dynamic address consumer level services, but that users can 
apply for an exemption with their ISP.  Power user ISPs such as those 
that offer static IP would not be blocked by default.  It also bears 
considering that, present company excluded, the number of people who 
legitimately use outbound port 25 on consumer ISPs is a vanishingly 
small number.  Is it really worth allowing so much abuse to continue 
just to preserve this luxury for a few people who could use one of the 
alternatives above?

Similiarly, your suggestion to universally implement SPF would require 
that every domain and mail server on the planet to implement your 
solution, versus port 25 blocking which would only require a few power 
users to make some changes.  Which is more likely to happen?

I agree with Larry.  It's well past time to implement this on all 
consumer level ISPs.

-- 
James Lick -- 黎建溥 -- [email-masked] -- http://jameslick.com/

---

From: "George Ou" <[email-masked]>
Date: Tue, 12 Apr 2005 02:01:05 -0700

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
James Lick
Sent: Tuesday, April 12, 2005 12:42 AM
To: [email-masked]
Subject: Re: [Asrg] article: port 25 blocking

>Similiarly, your suggestion to universally implement SPF would require that
every domain and mail server on the planet to implement your solution,
versus port 25 blocking which would only require a few power users to make
some changes.  Which is more likely to happen?

>I agree with Larry.  It's well past time to implement this on all consumer
level ISPs.

>--
>James Lick -- ??? -- [email-masked] -- http://jameslick.com/

James,

I have to respectfully disagree with you.  I've read your take on spam
before and I agree with most of it.  This is one of the few areas where I
disagree with you.

Blocking port 25 or demanding SPF is conceptually the same by dealing with
the problem from the opposite ends of the spectrum.  The question is do we
use an ACL that forbids all non-SMTP servers or do we use an ACL that only
permits all legitimate SMTP servers?  It would seem to me that non-SMTP
nodes on the net vastly out weigh legitimate SMTP servers and therefore
would be a much smaller ACL to deal with.  Permitting only legitimate SMTP
servers via SenderID lookup follows the "least privileges" rule and is a
much more effective ACL.  Anyone who blocks all non-SPF compliant messages
blocks all illegitimate SMTP servers using a database (public DNS records)
that they don't need to personally manage.  Creating or managing a massive
database of non-SMTP servers is totally impractical.

What makes you think that it takes "ALL domains" to implement SPF?  Just the
top 50 domains in the world alone implementing it would pretty much force
the entire world to comply unless they don't care for their messages to be
delivered to the 50 largest domains.  Do you honestly believe you can get
all ISPs and hotspots to manage a much larger non-SMTP server ACL?

Here is a more detailed write up on this.
http://blogs.zdnet.com/Ou/index.php?p=51
Let me know what you think.

George Ou

---

From: "Larry Seltzer" <[email-masked]>
Date: Tue, 12 Apr 2005 06:20:58 -0400

I had a thought yesterday that I wish I had before I hit the publish button
on the article: Perhaps the answer for people who need an exception case for
port 25 blocking is port 587 or even some non-standard port. I checked and
my own mail server supports both. Put SMTP on port 1125 or something like
that for your external users, or use 587 and require authentication. Is
there a reason this wouldn't work?

I'm also going to contact SBC and ask them how their opt-out system is
working so far.

LJS

---

From: William Leibzon <[email-masked]>
Date: Tue, 12 Apr 2005 07:11:54 -0700 (PDT)

> there a reason this wouldn't work?

Several issues:
1. Some locations (specially airport wireless, etc) actually do full
    port filtering in way that only well known ports are open. Anything
    new (and that includes port 587 unfortunetly) is not on their list.
2. A non-standard port that is 100% open just like regular SMTP is bound
    to soon be known and start to be abused. It has to be some type of
    restricted profile smtp with authentication (which is what submit is,
    so why reinvent it...).

---
William Leibzon
   mailto: [email-masked]
Anti-Spam and Email Security Research Worksite:
   http://www.elan.net/~william/emailsecurity/
Whois & DNS Network Investigation Tools:
   http://www.completewhois.com

---

From: "Larry Seltzer" <[email-masked]>
Date: Tue, 12 Apr 2005 10:02:33 -0400

>>http://www.completewhois.com

Hey, I'm a big fan. Good site.

>>1. Some locations (specially airport wireless, etc) actually do full
    port filtering in way that only well known ports are open. 

I guess this only works if 587 becomes "well-known" in this sense, but that
doesn't seem unreasonable. Blocking it by default is probably a mistake.

>>2. A non-standard port that is 100% open just like regular SMTP is bound
    to soon be known and start to be abused. 

That would be true if everyone used the same one, but if small numbers of
people are involved you just pick a number out of a hat that doesn't
conflict with an existing one. I suppose a really sophisticated worm could
sniff all traffic looking for where the mail is going, but we're nowhere
near there yet. If there are more than a few people involved then a real
authentication facility is probably advisable anyway. 

Larry Seltzer
eWEEK.com Security Center Editor
http://security.eweek.com/
http://blog.ziffdavis.com/seltzer
[email-masked]

---

From: James Lick <[email-masked]>
Date: Tue, 12 Apr 2005 23:00:02 +0800

George Ou wrote:

>Permitting only legitimate SMTP

Port 25 blocking is also a least privileges model.  Consumer ISPs block 
all outgoing port 25, then punch a few holes in the firewall for their 
own mail servers and the few customers that request an exemption.  
Sounds quite manageable to me.

>all ISPs and hotspots to manage a much larger non-SMTP server ACL?

I think you just answered your own question.  In summary you are saying 
that if the large domains require SPF then everyone will be forced to 
put SPF records in for any domain that sends email.  So you are in fact 
saying that yes, everyone will be forced to implement SPF records in 
your scheme.  I submit that no ISP is willing to risk the loss of 
requiring SPF because doing so would lose a vast amount of legitimate 
email.  In the current environment at best you would be able to get 
sites to reject on SPF hard fail, but that wouldn't achieve your goal.  
It's a chicken and egg problem that I don't think any ISP in their right 
might would go along with.

Your blog says that port 25 blocking is controversial with users.  I 
submit that it is controversial to a miniscule number of users.  On the 
other hand, requiring an SPF pass on all incoming email right now would 
cause huge amounts of legitimate mail to be blocked.  How controversial 
do you think that will be?  Already we have a number of respected 
anti-spammers who are quite opposed to SPF because hard fails are 
occasionally false positives.  You're gonna have people bouncing off the 
walls if you reject soft fail and unknown status and only allow SPF pass 
messages.

Implementing port 25 blocking also requires significant work, but the 
downside is limited to only a few people.  Also the number of consumer 
ISPs is much smaller than the number of email domains out there.  If you 
got the top 50 consumer ISPs to implement port 25 blocking, then nobody 
else has to do anything at all and you'll probably be at least 80% of 
the way done in terms of number of zombies no longer effective.

A number of large consumer ISPs have already implemented it with only a 
few grumbles about it.  Consumer ISPs which implement it will see an 
immediate reduction of complaints coming into their abuse mailbox, and 
only have a handful of users who will need to make a change.  That 
sounds a heck of a lot more manageable than forcing everyone to 
implement SPF records and having tons of legitimate mail rejected until 
everyone complies.

---

From: "George Ou" <[email-masked]>
Date: Tue, 12 Apr 2005 11:03:48 -0700

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
James Lick
Sent: Tuesday, April 12, 2005 8:00 AM
To: [email-masked]
Subject: Re: [Asrg] article: port 25 blocking

>Port 25 blocking is also a least privileges model.  Consumer ISPs block all
outgoing port 25, then punch a few holes in the firewall for their own mail
servers and the few customers that request an exemption.  
Sounds quite manageable to me.

How can it be "least privileges" unless you micromanage IP ACLs?  All it
takes is a few ISPs to not participate and you have leakage.  There are also
lots of non-consumer IP blocks out there too.  Permitting only SPF compliant
servers has virtually no leakage.

At some point, we're going to have to bite the bullet and adopt some sort of
domain level authentication.  Email is a server problem that is best handled
at the DNS and SMTP servers.  Don't try to push this off to the network
administrators and router ACLs.

>Your blog says that port 25 blocking is controversial with users.  I submit
that it is controversial to a miniscule number of users.  On the other hand,
requiring an SPF pass on all incoming email right now would cause huge
amounts of legitimate mail to be blocked.  How controversial do you think
that will be?  Already we have a number of respected anti-spammers who are
quite opposed to SPF because hard fails are occasionally false positives.
You're gonna have people bouncing off the walls if you reject soft fail and
unknown status and only allow SPF pass messages.

SPF enforcement would work if the top 50 ISPs implemented it in unison.
They don't need to implement a hard fail at first, maybe a 48 delay and slap
a "non-SPF" warning on every subject header.  Then start jacking it up to 4
days, 8 days, and then hard fail.  Is this easy?  No.  But we need to stop
skirting beating around the bush and start dealing with the real problem.

George

---

From: Markus Stumpf <[email-masked]>
Date: Tue, 12 Apr 2005 22:08:34 +0200

> which would effectively make port 25 blocking moot.

Sorry, this is not how SPF works.

Nothing prevents a spammer from getting throwaway domains, adding TTL 300
SPF records and using some 10000 cracked hosts on broadband access to spam.

The .DE TLD alone has currently more than 7 million domains. According to SPF
activists 700,000 domains worldwide now use SPF. This is less than 0.1% of all
domains worldwide. Happy deployment.

SPF is NOT an anti-spam method, it is a method for accreditation. It will
not stop spammers abusing cracked hosts on broadband access. Port 25 blocks will
do this. MTAMARK can help do this without port 25 blocking.

Everything that utilizes the forward domain, which is under full control of the
spammers, will be rather useless unless we have widely deployed Accreditation
Services and these will have tons of other problems associated with.. This is the
reason why even CSV (Certified Server Validation) will be of minor success.

	\Maex

-- 
SpaceNet AG            | Joseph-Dollinger-Bogen 14 | Fon: +49 (89) 32356-0
Research & Development |       D-80807 Muenchen    | Fax: +49 (89) 32356-299
"The security, stability and reliability of a computer system is reciprocally
 proportional to the amount of vacuity between the ears of the admin"

---

From: "George Ou" <[email-masked]>
Date: Tue, 12 Apr 2005 14:50:00 -0700

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
Markus Stumpf
Sent: Tuesday, April 12, 2005 1:09 PM
To: George Ou
Cc: [email-masked]
Subject: Re: [Asrg] article: port 25 blocking

On Mon, Apr 11, 2005 at 11:37:05PM -0700, George Ou wrote:
>> *  Start banning all non-SPF compliant domains within a certain 
>> deadline which would effectively make port 25 blocking moot.

>Sorry, this is not how SPF works.

Says who?  SPF blocks all hosts that are not registered as SMTP servers in
their domain's authoritative DNS servers.  That DOES make blocking consumer
outbound 25 moot.

I never claimed SPF stops spammers from using stolen SMTP credentials.  This
same issue applies to port 25 blocking as well.  SPF does make it possible
to block abusive or irresponsible domains.

---

From: Seth Breidbart <[email-masked]>
Date: Tue, 12 Apr 2005 18:39:11 -0400 (EDT)

> their domain's authoritative DNS servers.  That DOES make blocking consumer

Markus is right.  What is "their domain"?  It's the domain the trojan
_claims_ it to be.  Who owns that domain?  The spammer.  What does the
spammer's SPF server say the authorized mail sender for that domain
is?  The machine with the trojan on it.

>>Nothing prevents a spammer from getting throwaway domains, adding
>>TTL 300 SPF records and using some 10000 cracked hosts on broadband
>>access to spam.
>
> I never claimed SPF stops spammers from using stolen SMTP
> credentials.

The smtp credentials aren't stolen, they were purchased by the spammer
with the domain.

>  This same issue applies to port 25 blocking as well.

No, it doesn't.  If the ISP blocks port 25, stuff doesn't get out.  If
I require an SPF pass, the spam passes.

>  SPF does make it possible to block abusive or irresponsible
>  domains.

Yes, it does.  Are you going to maintain that list accurately and as
quickly as spammers buy more domains?

Seth

---

From: Claus Assmann <[email-masked]>
Date: Tue, 12 Apr 2005 15:27:46 -0700

> >Markus Stumpf:

> their domain's authoritative DNS servers.  That DOES make blocking consumer

MTAmark would be right "technology" for this. SPF is not suitable
for this purpose (as Markus explained.)

---

From: Frank Ellermann <[email-masked]>
Date: Wed, 13 Apr 2005 00:54:15 +0200

> Sorry, this is not how SPF works.

A receiver could try to "enforce" it, but one of its strong
points is that it's a _voluntary_ system working without any
"worldwide deployment" FUSSP.

> less than 0.1% of all domains worldwide

If the users of these domains don't get the tons of bounces
anymore they got before it's fine for all participants.

Even the evil third in this game can simply switch to one
of the remaining 99.9% domains, all participants are happy.
It's not a trick, it's SPF.

> It will not stop spammers abusing cracked hosts on 
> broadband access.

True.

> Port 25 blocks will do this.

IBTD.  A zombie minus port 25 is still a zombie.  SpamCast
pretends that blocking port 25 is an adequate replacement
of a proper abuse desk, but that's a lie.

> MTAMARK can help do this without port 25 blocking.

Indeed, it could be used as input for DynIP BLs.  Or for
SIQ servers.  SIQ could support SPF or Sender-ID or wild
mixtures of RFCI cum MTAMARK times CSV modulo SPF.

                     Bye, Frank

---

From: Bill Cole <[email-masked]>
Date: Tue, 12 Apr 2005 18:26:16 -0400

>which would effectively make port 25 blocking moot.

SPF '-all' publishing and enforcement has not proven feasible for 
domains of any significant scale and/or user diversity. Without all 
domains publishing '-all' record along with a large fraction of 
receiving systems being willing to enforce those records, SPF use 
cannot reduce the utility of port 25 blocking.

Beyond that, any proposal that requires everyone to make changes on 
the same schedule or else the first movers will break their systems 
badly, is simply never going to happen at all on any schedule. SPF as 
the FUSSP requires behavior that is self-harming unless everyone else 
does it at the same time.

>who won't implement some reasonable rate limiting schemes.

Who is 'we' and how do you propose 'we' deal with such ISP's? Most of 
the larger ISP's  for years have been making business decisions fior 
a decade in support of continuing the growth of spam and the spread 
of the malware used to send most modern spam, and there has been no 
'we' willing and able to 'deal' with them in any serious and 
consistent way for all of that time.

>we confiscate the bond for any kind of abuses from an SPF abusive domain.

The owners of the mail systems I work with are not going to pursue 
anyone's certification and are unlikely to trust any certification 
that anyone issues. Even those which send some bulk mail and those 
who are inundated by it have seen no value in certification systems 
like Habeas or Ironport's Bonded Sender. Such systems have proven in 
the marketplace to be of very limited interest and utility.

>collateral damage.

You've got a very odd idea of what constitutes 'collateral damage' if 
you believe that requiring that all domain owners make mandatory 
changes, establishing a new enforcement authority, and creating a new 
certifying authority to bless domains constitutes less damage than 
inconveniencing a single-digit percentage of individual end users.

>to put in a few SPF records than blocking my outbound port 25 access.

I see. Those steps seem less damaging to you because they cause less 
damage to you.

Have you looked at how port 25 blocking is actually being done by 
even the minimally competent ISP's? SBC is an example of one such. 8 
months ago they had a press release and sent mail to all customers 
about the coming rollout of port 25 blocking. With that they included 
a way to preemptively request exemption and they made clear that 
customers with static address accounts would be excluded by default. 
To my profound shock, SBC has actually managed to execute that 
rollout with reasonable speed and accuracy. There may well be some 
ISP's who are implementing port 25 blocking without exempting users 
with static IP assignments, but I believe they would be the minority. 
SBC's willingness to provide exceptions for anyone who asks may be 
unusual, but it is not unique.

Note that I DO NOT argue that port 25 blocking is a panacea. It is a 
generally negative thing, but as long as ISP's insist on offering 
services in ways that encourage customers to view their own computers 
and network connection as an appliance requiring no more thought than 
a toaster or a telephone, the customers of that sort of service 
should be surrounded by significant impediments to their 
exploitation, which intrinsically includes impediments to their 
misuse of the network at large where people who are competent to 
handle an unfettered link operate. It is unfortunate that no useful 
consensus is possible on what constitutes 'competent' in this 
context, so the evolving proxy for competence is willingness and 
ability to find and pay for an account that is not restricted.

>We're

Yes, and because the two yield logically identical results, either 
ends up as a default assumption of invalidity and some system where 
the legitimate systems are blessed. This is how port 25 blocking is 
done: network owners who are the best authorities on the nature of 
their address space and its use decide where to allow port 25 
traffic. If they decide to only service people who have no desire for 
full service, they can do so. If they decide to charge a little more 
for full service, they can do that. If they decide that full service 
is available to anyone who knows that they want it, that is also 
feasible.

-- 
Bill Cole
[email-masked]

---

From: Bill Cole <[email-masked]>
Date: Tue, 12 Apr 2005 19:32:23 -0400

At 6:20 AM -0400 4/12/05, Larry Seltzer wrote:
>port 25 blocking is port 587

Yes, in most cases. Port 587 is the standard port for initial mail 
submission, a protocol so closely related to SMTP that most MUA's 
don't even have to know that they are speaking it instead of SMTP.

People who are not doing initial mail submission and want port 25 for 
things they should not try to do on port 587 instead probably should 
not be doing that from a dynamically assigned address anyway, unless 
they have deep support from their ISP for that sort of use, including 
dynamically assigned reverse DNS records and other such oddities only 
witnessed in corporate networks and dreams born of jalapeno and 
anchovy pizza...

>  or even some non-standard port.

No. Please no. I beg you: do not suggest the use of 'some 
non-standard port' for anything in a published article.

>I checked and
>my own mail server supports both.

Any modern MTA worth using will support port 587 use, and most will 
allow you you put the listener on any arbitrary port. The latter 
should be reserved for carefully considered and highly unusual 
circumstances.

>  Put SMTP on port 1125 or something like
>that for your external users,

Please, no. There are standards for using non-standard ports. Using 
otherwise assigned ports is a generally bad idea.

>or use 587 and require authentication. Is

Sturgeon's Law always applies, but there is no other reason I've seen.

Yes, people use garbage MTA's and/or firewalls and/or configure one 
or both  poorly. At least one ISP briefly has blocked port 587 out of 
what can most charitably described as overzealousness.

>I'm also going to contact SBC and ask them how their opt-out system is

Based on the traffic in the private sbcglobal.help.* newsgroups, it 
seems to be working well, but of course the population of people who 
would manage to share experiences there is likely not a random 
representative sample. A somewhat differently skewed sample of 19 
people working in an IT firm with SBC DSL accounts found 2 with 
static accounts (no block) 1 who used the preemptive opt-out 
successfully, and 3 who think their machines got faster since the 
first of the year.

On the negative side, those same SBC  (user to user) help newsgroups 
have shown some reports of what looks like SBC cutting off users from 
the smtp.$SBCUNIT.yahoo.com mail servers that are part of the 
SBC-Yahoo unnatural act.

-- 
Bill Cole
[email-masked]

---

From: "George Ou" <[email-masked]>
Date: Tue, 12 Apr 2005 16:27:49 -0700

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Bill
Cole
Sent: Tuesday, April 12, 2005 3:26 PM
To: [email-masked]
Subject: RE: [Asrg] article: port 25 blocking

>SPF '-all' publishing and enforcement has not proven feasible for domains
of any significant scale and/or user diversity. Without all domains
publishing '-all' record along with a large fraction of receiving systems
being willing to enforce those records, SPF use cannot reduce the utility of
port 25 blocking.

>From the way you make it sound, it sounds like we will NEVER have any kind
of domain level authentication and the "from:" address will remain on the
honor system.  Since it appears that there is no consensus for any one's
solution be it SPF enforcement or port 25 blocking, you might be right about
that so the future remains bleak.

>Beyond that, any proposal that requires everyone to make changes on the
same schedule or else the first movers will break their systems badly, is
simply never going to happen at all on any schedule. SPF as the FUSSP
requires behavior that is self-harming unless everyone else does it at the
same time.

If we could get the top 50 domains to start "punishing" non-SPF compliant
with delays and a gradual migration to a hard fail in unison, would that not
prompt other domains to become SPF compliant?

George

---

From: "George Ou" <[email-masked]>
Date: Tue, 12 Apr 2005 17:01:52 -0700

-----Original Message-----

>Have you looked at how port 25 blocking is actually being done by even the
minimally competent ISP's? SBC is an example of one such. 8 months ago they
had a press release and sent mail to all customers about the coming rollout
of port 25 blocking. With that they included a way to preemptively request
exemption and they made clear that customers with static address accounts
would be excluded by default. 
To my profound shock, SBC has actually managed to execute that rollout with
reasonable speed and accuracy. There may well be some ISP's who are
implementing port 25 blocking without exempting users with static IP
assignments, but I believe they would be the minority. 
SBC's willingness to provide exceptions for anyone who asks may be unusual,
but it is not unique.

You're always free to implement port 25 blocking on your side for inbound
traffic which effectively achieves the same thing for your network.  You
just need to implement a large ACL yourself that might be synchronized with
a large shared database somewhere on the net.  Why do you want everyone else
to implement outbound port 25 blocks for you?

Bottom line is, you'll have the same problem convincing people to block
outbound 25 as you will convincing them to implement SPF.  SPF just happens
to be a better solution in my opinion.

George

---

From: "George Ou" <[email-masked]>
Date: Tue, 12 Apr 2005 17:07:45 -0700

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Bill
Cole
Sent: Tuesday, April 12, 2005 4:32 PM
To: [email-masked]
Subject: RE: [Asrg] article: port 25 blocking

>People who are not doing initial mail submission and want port 25 for
things they should not try to do on port 587 instead probably should not be
doing that from a dynamically assigned address anyway, unless they have deep
support from their ISP for that sort of use, including dynamically assigned
reverse DNS records and other such oddities only witnessed in corporate
networks and dreams born of jalapeno and anchovy pizza...

The standard firewall configuration is to block all traffic unless otherwise
specified.  While it's true that most SMTP servers will accept port 587,
most firewall policies only permit inbound TCP 25 to an SMTP server.  Call
this overzealousness if you will, but it's a simple reality.

George

---

From: Seth Breidbart <[email-masked]>
Date: Tue, 12 Apr 2005 20:58:10 -0400 (EDT)

"George Ou" <[email-masked]> wrote:

> You're always free to implement port 25 blocking on your side for
> inbound traffic which effectively achieves the same thing for your
> network.  You just need to implement a large ACL yourself that might
> be synchronized with a large shared database somewhere on the net.

Where, precisely, is the large accurate shared database?

Every ISP knows which of its IP addresses hold machines that ought to
be allowed to send email directly outside its network.  That's local
knowledge.  Nobody has complete and accurate global knowledge.

>  Why do you want everyone else to implement outbound port 25 blocks
>  for you?

Because they're the ones with the accurate information.

> Bottom line is, you'll have the same problem convincing people to
> block outbound 25 as you will convincing them to implement SPF.

They can do both.  But blocking port 25 causes their network to send
me a lot less spam, which gets them fewer complaints and makes their
legitimate email less likely to be blocked.  Some networks like that.

>  SPF just happens to be a better solution in my opinion.

Not in the opionion of many others, some of whom are a lot more
influential.

Seth

---

From: Seth Breidbart <[email-masked]>
Date: Tue, 12 Apr 2005 21:13:44 -0400 (EDT)

"George Ou" <[email-masked]> wrote:

> The standard firewall configuration is to block all traffic unless
> otherwise specified.

Which RFC defines that "standard"?

>  While it's true that most SMTP servers will accept port 587,
> most firewall policies only permit inbound TCP 25 to an SMTP server.

"most" out of precisely how many you surveyed?

And the smtp server needs to know to treat 587 differently (clients
must be identified), so it should know to accept connections there.

>  Call this overzealousness if you will, but it's a simple reality.

In which universe?

Seth

---

From: Markus Stumpf <[email-masked]>
Date: Wed, 13 Apr 2005 03:24:45 +0200

On Tue, Apr 12, 2005 at 08:58:10PM -0400, Seth Breidbart wrote:
> be allowed to send email directly outside its network.

I doubt that.
If we give e.g. a /28 to a (business) customer we don't know which IP the
mailserver will be on (if any). I don't think we are different with this regard to
the majority of all other ISPs.
We get a hint if the customer wants us to set up revDNS and add a RR that points
to a machine named "mail" or "exchange" but sometimes the name is "www" or even
"snoopy".

> That's local

But that could be made public with MTAMARK ;-)))

> legitimate email less likely to be blocked.  Some networks like that.

And it is *much* easier deployed.
There is a big difference between 5 or 10 rules in 2 to 20 border routers and
SPF lines in some 10K domains and also to the RRs in those domains.

	\Maex

---

From: Seth Breidbart <[email-masked]>
Date: Tue, 12 Apr 2005 21:56:59 -0400 (EDT)

Markus Stumpf <[email-masked]> wrote:
> If we give e.g. a /28 to a (business) customer we don't know which
> IP the mailserver will be on (if any). I don't think we are
> different with this regard to the majority of all other ISPs.

If you're an ISP giving a subnet to a business (or a smaller ISP),
then as far as you're concerned they're welcome to put their
mailswerver on any of their IP addresses, so you don't have to block.
It's their problem.

Seth

---

From: Devdas Bhagat <[email-masked]>
Date: Wed, 13 Apr 2005 07:29:53 +0530

> Which RFC defines that "standard"?
You don't need a RFC for that. That is canonical default policy.

> "most" out of precisely how many you surveyed?
Are we speaking inbound to MX servers, or about outbound SMTP servers?
Would your outbound SMTP servers not be inside your firewall? Or at
least in the DMZ? And given that adjusting firewall rules for a whole
baggage of other protocols is acceptable (voice and OWA come to mind),
why not use a proper SMTP server as an application layer gateway for
SMTP services?

Devdas Bhagat

---

From: Frank Ellermann <[email-masked]>
Date: Wed, 13 Apr 2005 03:59:04 +0200

George Ou wrote:

> If we could get the top 50 domains to start "punishing"
> non-SPF compliant with delays and a gradual migration to
> a hard fail in unison, would that not prompt other domains
> to become SPF compliant?

Something with your definition of "non-SPF compliant" is wrong.

"v=spf1 -ip4:127.0.0.1 +all" is perfectly compliant, it could
even make sense.  And if not it's easy to find cases where +all
is _very_ useful, see the recent include:not.me discussion on
the spf-discuss mailing list.

"v=spf1 a ~all" is also perfectly compliant, the latest draft
proposes to process a SOFTFAIL in a greylisting-style.

Something like "v=spf1" (implicitly the same as "v=spf1 ?all")
or many other policies ending with "?all" might be useless, but
they are still "compliant".  And there are cases where a "?"
NEUTRAL result is exactly what the sender wanted, e.g.

"v=spf1 mx ?a:sometimes.i.use.a.spamcast.mta.example -all"

But maybe you define "compliant" as "no sender policy is bad".
That's not true, because it's relatively easy for spammers to
get an SPF PASS if they want it:

"v=spf1 +exists:%{ir}.comcast.blackholes.us -all"

This policy radically PASSes for all spamcast zombies, and it
is again relatively simple to get a similar effect with a less
obvious policy.

In other words PASS is meaningless unless it's from somebody
you already know (e.g. paypal).  SOFTFAIL could be useful.  But
the full power of SPF is FAIL, because receivers can reject it.

That forces spammers to forge another domain.  No more bogus
bounces / challenges / vacation / what else mails to the owners
of SPF-FAIL protected domains.

Effect on spam:  zero, they just forge another domain.  Effect
on SMTP:  nice, SMTP only works if the whole world does _not_
stop to send bounces etc. or delete them automatically on sight.

If you really think that SPF is a FUSSP (IMNSHO it is not) you
have to add meaning to a PASS (PASS from ebay vs. PASS from an
unknown stranger), and for that you need white lists of known
senders, and the only obvious way to create them on the fly is
some kind of C/R system <shudder />

Otherwise SPF is unrelated to anti-spam, like "port 25 blocks"
are unrelated to anti-zombie, and Sender-ID is unrelated to
anti-phishing.
                              Bye, Frank

---

From: Daniel Feenberg <[email-masked]>
Date: Wed, 13 Apr 2005 08:06:08 -0400 (EDT)

> to implement outbound port 25 blocks for you?

The advantage that the source ISP has is that they have actual knowledge
of which IP addresses are dynamic and which are not. The receiving MTA can
use DNSBLs and the RDNS to guess, but it seems that a fair number of ISPs
give dynamic looking addresses to customers with legitimate mail servers.  
Not a good idea, but the customer will likely not know why there mail is
often rejected. Of course, the ISP could inform the DNSBLs of which
addresses were dynamic, which would allow the DNSBL to be just as accurate
as the outbound port 25 block.

One advantage of using DNSBLs rather than blocking port 25 is that it
enhances the value of DNSBLs. If more MTAs use a good DNSBL that helps
control spam from static addresses. Otherwise, I hardly think it makes a
difference if the packets are stopped at the outbound router or the
receiving MTA. It is just a couple of packets - not the entire spam
message.

The worst spam crime has to be mixing spam with legitimate mail from the
same address. If an address sends only spam, it is easy enough to ignore.

---

From: Barry Shein <[email-masked]>
Date: Wed, 13 Apr 2005 16:16:29 -0400

OTOH, rate-limiting port 25 probably would be a reasonable compromise
if the rates were set reasonably.

Unfortunately, easier said than done.

-- 
        -Barry Shein

Software Tool & Die    | [email-masked]           | http://www.TheWorld.com
Purveyors to the Trade | Voice: 617-739-0202        | Login: 617-739-WRLD
The World              | Public Access Internet     | Since 1989     *oo*

---

From: Barry Shein <[email-masked]>
Date: Wed, 13 Apr 2005 16:13:36 -0400

> prompt other domains to become SPF compliant?

I'd imagine if the top 50 domains refused e-mail unless one was
wearing a funny hat you'd see a lot more people wearing funny hats.

But what effect that would have on spam per se, like SPF, is highly
questionable.

-- 
        -Barry Shein

---

From: mathew <[email-masked]>
Date: Thu, 14 Apr 2005 20:00:10 -0500

>    restricted profile smtp with authentication (which is what submit is,

Right--there's no point in blocking port 25 if you just open up another 
port to plain unauthenticated SMTP. All you're doing then is 
inconveniencing many people by changing the standard port number for 
SMTP; you're not actually improving security at all. Botnets will just 
start probing all the common SMTP ports rather than the standard one.

On the other hand, if you implement SMTP authentication, there's no need 
to block port 25, and you make the bot-programmer's work harder, or even 
impossible if the user's mail client uses a properly-implemented 
lockable keychain.

So instead of wasting time playing move-the-port and annoying people, 
just implement SMTP authentication. I mean, even my Palm handheld and my 
mobile phone know about SMTP AUTH these days.

mathew

---

From: der Mouse <[email-masked]>
Date: Thu, 14 Apr 2005 21:36:56 -0400 (EDT)

>> [...]
> Right--there's no point in blocking port 25 if you just open up
> another port to plain unauthenticated SMTP.

Agreed.

> On the other hand, if you implement SMTP authentication, there's no
> need to block port 25, and [...]

Except for the important point that the entity (putatively)
implementing SMTP AUTH or using another port usually is not the same
entity as the one (putatively) blocking port 25.  In the classic
road-warrior scenario, the entity blocking port 25 is the dialup ISP
used when on the road and the entity whose SMTP server is being futzed
with is the organization who's "home" to the road-warrior.

/~\ The ASCII				der Mouse
\ / Ribbon Campaign
 X  Against HTML	       [email-masked]
/ \ Email!	     7D C8 61 52 5D E7 2D 39  4E F1 31 3E E8 B3 27 4B

---

From: "Larry Seltzer" <[email-masked]>
Date: Thu, 14 Apr 2005 21:52:28 -0400

>>Right--there's no point in blocking port 25 if you just open up another
port to plain unauthenticated SMTP....

Don't get me wrong, this was just a crazy off-the-top-of-my-head idea and I
can certainly believe I'm wrong, but this reasoning doesn't persuade me.
There's no reason to believe that there would be a few common ports. 

Let's say I want to let my team of users access the mail server from their
ISP accounts. I set up SMTP on (pull number out of ass) TCP 48207. I have to
set this up on all their clients (and open it up on any firewalls between
us), so for practical purposes it can't be too many of them. 

Assuming the ISP hasn't blocked that port as well (ISP's don't generally
block arbitrary ports) it should solve the problem of getting through the
port 25 block. *Conventional* worms on the system will still fail because
they will be trying to use port 25. A new worm could be written to monitor
all communications looking for SMTP on non-standard ports, but this is a lot
of work when there is still low-hanging fruit out there.

So how is this not going to solve anything? I agree I'd much rather have
users run port 587 and authenticate, but if it's just your sense of
networking asthetics that's offended by this scheme then that's worth
saying.

Larry Seltzer

---

From: Bill Cole <[email-masked]>
Date: Thu, 14 Apr 2005 23:00:22 -0400

>networking asthetics that's offended by this scheme then that's worth

That certainly is a workable approach, but it may well not be as 
usable as the port 587 approach, since there are probably marginally 
fewer mail clients capable of arbitrary port usage than are capable 
of using port 587 (or the non-standard but unfortunately still widely 
deployed port 465.) If you can put a  non-authenticated SMTP on an 
arbitrary high port, you can probably put it on port 587 just as 
easily.

However, there's really no excuse for anyone putting an 
unauthenticated SMTP for mail submission on any port. Requiring 
authentication makes a higher bar for malware to get over, and it 
really is the malware at this point that is the driving motivator for 
port 25 blocking by connection providers. Requiring authentication 
does not necessarily make it impossible for some trojan to sniff out 
how to send mail on a misdesigned system, but it generally easier to 
dig up basic config information than to find passwords.

Bottom line: putting unauthenticated SMTP for initial mail submission 
on some port other than 25 gets around port 25 blocking and presents 
no significant danger *today* but it has its own deployment problems 
for client systems and is likely to fall to the next generation of 
malware well before they figure out how to get around existing 
systems for password security and so crack authenticated SMTP.

-- 
Bill Cole
[email-masked]

---

From: mathew <[email-masked]>
Date: Thu, 14 Apr 2005 23:01:03 -0500

>us), so for practical purposes it can't be too many of them.

Let's start with why this proposal won't work.

Basically, it's security through obscurity. And in this case, the 
obscurity will only last until the first port scan. There are only 65535 
ports in total; there are plenty of tools out there which will scan them 
all in a couple of minutes; adding code to go back to each open port and 
check for an SMTP server is a trivial addition.

Like every cable modem user, I already get port scanned regularly by 
malware. As soon as any significant number of SMTP servers start using 
random unadvertised ports for unauthenticated SMTP, the port scanning 
0wn3d machines already out there will find out what those ports are. The 
spammers will simply add the port number to each address on the lists of 
open relays they already exchange with each other.

Remember, they don't care if the port scan sets off alarm bells and gets 
the scanning machine's owner into trouble, because they're using 
botnets. In fact, good luck even detecting a port scan when it's coming 
from 10,000 different IP addresses over the course of a month.

So all you'll have done is slowed the spammers for maybe a few weeks or 
a few months, depending on how long your scheme takes to become popular 
and how long it takes them to take their existing port scan code and use 
it to scan your server. Then you'll be back to square one, except you'll 
have the added support burden of having to explain to grandma what a 
port number is, and why it's different for her account than it is for 
the account of her friend that helped her set up the computer, and what 
she should do to use her e-mail client that doesn't allow arbitrary 
random port numbers to be entered.

>port 25 block.
The *problem* is spam. Blocking port 25 was supposed to be a *solution*. 
Instead, it causes a problem, and doesn't stop or slow spam for any 
significant period of time.

>A new worm could be written to monitor all communications looking for SMTP on non-standard ports, but this is a lot
It's also a lot of work when you can just port scan the server, or use 
the list of server:port combinations you obtained from your spamware 
supplier.

So, it won't work. Now for some additional reasons why it's a bad idea.

First off, plenty of places only allow connections on known ports. The 
company I work for has a hard enough time getting clients to allow VPN 
connections, let alone SMTP on port 13281. There's a reason why IPSec is 
gradually disappearing and being replaced by SSL-based VPN.

Secondly, while it's common for software to implement SMTP 
authentication, it's uncommon for it to allow the user to set whatever 
random port number he likes. My phone won't allow that, for instance.

Third issue: one of the reasons we have ports in the first place is so 
that you don't get someone's FTP data session coming in on the port your 
SMTP server is connected to. There's a finite set of ports available, 
and if you start using random *necessarily undocumented* ports for your 
servers, the chance of a client talking protocol X hitting a server 
talking protocol Y increases. Better hope the client checks the server 
is talking the right protocol, and doesn't dumbly retry, or your mail 
server logs are going to fill up pretty quickly.

For problem four, let's imagine you're in charge of security for a big 
ISP. You have hundreds of corporate customers, so you'd like to be 
pro-active and watch out for intrusion attempts and have the system warn 
you. Well, now you have the problem of distinguishing between 1,000 
incoming legitimate SMTP connections on random ports caused by company 
employees sending mail via company servers, and a port scan from a 
botnet. The only way you'll be able to do it will be to do traffic 
analysis on every single incoming TCP/IP connection. That might make 
Cisco happy, because they'll be able to sell a ton of new routers, but 
it probably won't make anyone else happy.

Except that ironically, this exact same traffic pattern (incoming TCP 
connections on random ports eventually talking SMTP) is exactly what 
you'll be wanting to catch when it comes from botnets, because then 
it'll be spammers probing your customers for SMTP servers on random 
ports, rather than your customers connecting to their SMTP servers on 
random ports. So even traffic analysis won't help too much, because the 
new normal traffic pattern looks exactly like a botnet port scan.

Problem five is that another use for well-known ports is rate limiting, 
or to look at it from the other side, quality of service. Suppose you're 
in charge of networking for a major corporation. You'd probably like to 
be able to allocate a fixed minimum amount of bandwidth to SMTP, so that 
your employees can still send and receive e-mail no matter how many 
inconsiderate clods are downloading Linux ISOs via FTP. Except that now 
SMTP might be on any random port, so that's going to be more difficult 
than it used to be.

In fact, you don't even need to be a big company to have that issue--my 
home router has QoS features so I can make sure e-mail goes out even if 
the spouse or kids are uploading or downloading movies. Or at least, it 
does so long as the services I want to ensure have bandwidth, are on 
known ports...

Problem six is that it encourages spammers to generate more traffic and 
penetrate more systems. Even if we assume it does slow them for a few 
months, it's trivially defeatable if they do lots and lots of port 
scans, so guess what they're gonna be doing next year? I for one would 
rather not incent mass port scanning by botnets.

I'm sure the above isn't an exhaustive list of problems either. So, why 
not do the simpler thing that also happens to be more effective and less 
disruptive, and put authentication on your SMTP server?

I'm not saying that port 25 blocking is worthless; it's probably a 
reasonable idea under specific circumstances. That is, if a big ISP 
detects a suspicious number of outgoing SMTP connections from one of 
their customers to random machines on the Internet, it's probably worth 
blocking port 25 for that customer until the customer can explain what 
they're doing. It's probably better still (and simpler) to rate-limit 
SMTP, though.

Because of port scanning, blanket blocking of port 25 everywhere isn't 
*sufficient* as a solution to the spam problem. And since you can do 
authentication on SMTP on port 25, I think it's pretty clear that it 
isn't *necessary* either. So, we have something which is neither 
necessary nor sufficient to solve the spam problem, which causes all the 
headaches listed above. I think that qualifies it as a bad idea.

Since all the technical talk about ports and protocols is boring, I'll 
end with an analogy any random person should be able to appreciate: If 
you find that people are walking through your front door and stealing 
from your house, you can probably stop them for a little while, or at 
least slow them down, by bricking up the front door and leaving the back 
door open instead. But you know, it's not going to stop them for long, 
it's going to be a pain in the ass for you, and the real solution is to 
put a lock on the door.

mathew

---

From: Walter Dnes <[email-masked]>
Date: Fri, 15 Apr 2005 21:17:35 -0400

On Thu, Apr 14, 2005 at 11:01:03PM -0500, mathew wrote

> >Let's say I want to let my team of users access the mail server from
> >their ISP accounts. I set up SMTP on (pull number out of ass) TCP
> >48207. I have to set this up on all their clients (and open it up on
> >any firewalls between us, so for practical purposes it can't be too
> >many of them.
> > 
> >
> 
> obscurity will only last until the first port scan. There are only
> 65535 ports in total; there are plenty of tools out there which will
> scan them all in a couple of minutes; adding code to go back to each
> open port and check for an SMTP server is a trivial addition.

  Rather than accessing random open ports, the road warriors' machines
should be using ssh-tunneling or VPN or whatever.  I know from personal
experience that ssh-tunneling works over a NAT'ed connection, which can
break some VPNs.  Set up the sshd config to not accept passwords, i.e.
the client must use their key to authenticate.  Somebody with a traffic
sniffer sees encrypted traffic to port 22; like whoopee.

> 0wn3d machines already out there will find out what those ports
> are. The spammers will simply add the port number to each address
> on the lists of open relays they already exchange with each other.

  So the traffic-sniffer sees a bunch of encrypted traffic going to port
22 on the corporate server; again, like whoopee.

-- 
Walter Dnes <[email-masked]>
An infinite number of monkeys pounding away on keyboards will
eventually produce a report showing that Windows is more secure,
and has a lower TCO, than linux.

---

From: mathew <[email-masked]>
Date: Mon, 18 Apr 2005 21:48:00 -0500

Walter Dnes wrote:

>should be using ssh-tunneling or VPN or whatever.
>

In which case there's no need for the "random ports" proposal in the 
first place.

mathew

---

From: Matthew Elvey <[email-masked]>
Date: Tue, 19 Apr 2005 22:14:36 -0700

Ok, I think some clarification is in order.

On 4/12/2005 7:02 AM, Larry Seltzer sent forth electrons to convey:
 > <that random ports should be used, and that if 465/587 became common, 
spammers would adapt to using them instead of 25.>

Larry, I think you're a bit confused (assuming my paraphrasing of your 
statements is accurate).  465/587 are being suggested as alternatives 
for 25 because the ONLY way to send spam (or legitimate email) using 
SMTP is over port 25.  Let me explain.
Briefly (and with some simplification), this is how systems send mail to 
an Internet email address:
1) Look up the IP of the machine that receives mail for the domain. 
2) Open up a TCP connection to that IP ON PORT 25. 
3) Send the message. 
The machines that receive Internet email for domains via SMTP from 
systems with which there is no prior relationship do not receive that 
mail on ports other than TCP port 25.
There's no way that's going to change in the foreseeable future (ie. 
flying pigs, or 100% adoption of SPF WITH end-user roll-out, '-all' 
records AND SRS are more likely).
Let's assume that there's massive adoption of  mail submission via 
465/587, and of port 25 blocking.   It will still be the case that all 
mail sent via 465/587 will then be sent via the 3-step process above, 
via port 25.  So the port 25 blocking will remain effective.  It will 
not be possible for spammer's zombies to send mail by following the 
3-step process above. Why?  The only machines they will be able to reach 
via port 25 will be their/the zombie's ISP's mail servers.  And if they 
try to send spam via 465/587, they will be sending via machines that are 
relays, as these will be the only machines listening on those ports. 
These (closed) relays (which are not port 25-blocked) are managed by ISPs. 

Make sense?

BTW, have you looked at CSV?

---

From: "Larry Seltzer" <[email-masked]>
Date: Wed, 20 Apr 2005 06:07:35 -0400

>>....

>>Make sense?

Actually, no, I can't find the message with the exact quote from me you cite
and it's over a week ago so I don't remember exactly what the context was. I
think everything you say is obvious and I don't know what you're clarifying.

>>BTW, have you looked at CSV?  

Not in a long time.

Larry Seltzer

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
Matthew Elvey
Sent: Wednesday, April 20, 2005 1:15 AM
To: Larry Seltzer
Cc: [email-masked]
Subject: Re: [Asrg] article: port 25 blocking

Larry, I think you're a bit confused (assuming my paraphrasing of your
statements is accurate).  465/587 are being suggested as alternatives for 25
because the ONLY way to send spam (or legitimate email) using SMTP is over
port 25.  Let me explain.
Briefly (and with some simplification), this is how systems send mail to an
Internet email address:
1) Look up the IP of the machine that receives mail for the domain. 
2) Open up a TCP connection to that IP ON PORT 25. 
3) Send the message. 
The machines that receive Internet email for domains via SMTP from systems
with which there is no prior relationship do not receive that mail on ports
other than TCP port 25.
There's no way that's going to change in the foreseeable future (ie. 
flying pigs, or 100% adoption of SPF WITH end-user roll-out, '-all' 
records AND SRS are more likely).
Let's assume that there's massive adoption of  mail submission via 
465/587, and of port 25 blocking.   It will still be the case that all 
mail sent via 465/587 will then be sent via the 3-step process above, via
port 25.  So the port 25 blocking will remain effective.  It will not be
possible for spammer's zombies to send mail by following the 3-step process
above. Why?  The only machines they will be able to reach via port 25 will
be their/the zombie's ISP's mail servers.  And if they try to send spam via
465/587, they will be sending via machines that are relays, as these will be
the only machines listening on those ports. 
These (closed) relays (which are not port 25-blocked) are managed by ISPs. 

Make sense?

---

From: Matthew Elvey <[email-masked]>
Date: Wed, 20 Apr 2005 09:26:01 -0700

>Actually, no, I can't find the message with the exact quote from me you cite
I was paraphrasing, hence the <> and use of the words "that" and 
"paraphrasing".  Sorry if it wasn't clear enough for ya, or wasn't 
paraphrasing accurately, or mis-attributed - there were a lot of posts 
that were being quoted anonymously or with broken mail clients. 

PLEASE, FOLKS, IF YOUR MAIL CLIENT CAN'T QUOTE PROPERLY, USE ANOTHER 
ONE!  (USE A WEBMAIL CLIENT IF YOU CAN'T SWITCH YOUR MAIN CLIENT!)  (But 
if the quoting is already broken by someone else, removing the 
attribution is reasonable...)

>think everything you say is obvious and I don't know what you're clarifying.
Ok, then.  :)

>>>BTW, have you looked at CSV?  
If you've looked at it and understand it, that's fine.  It's not 
constantly changing and forking.  But code is being written. Thanks.
NRN.

---

From: Frank Ellermann <[email-masked]>
Date: Wed, 20 Apr 2005 19:50:47 +0200

Matthew Elvey wrote:

> It's not constantly changing and forking.

The MAY quasi-zone-cut stuff is rather new (Feb 20).

<rant mode="on"> Unlike SPF, where the removal of the
real zone-cut is not yet published in an I-D, and the
switch from "MAY test HELO" to SHOULD is also not yet
published. </rant>

> code is being written

Don't expect too much, even the "flying pigs" (as you
said) with an immediate obvious profit for senders and
receivers had some difficulties learning to fly.  Bye

---

From: Tony Finch <[email-masked]>
Date: Wed, 20 Apr 2005 19:22:26 +0100

>constantly changing and forking.  But code is being written.

My Exim CSA implementation works well and should be included in the
next release.

Tony.
-- 
f.a.n.finch  <[email-masked]>  http://dotat.at/
FAEROES SOUTHEAST ICELAND: EAST OR SOUTHEAST 4 OR 5. MAINLY FAIR. MODERATE OR
GOOD.