Re: Outgoing SMTP Servers

2011-11-03 Thread Bill Stewart
On Mon, Oct 31, 2011 at 6:23 AM, Brian Johnson  wrote:
> For clarity it's really bad for ISPs to block ports other than 25 for the 
> purposes of mail flow control... correct?
Yes, correct.  If you're using another mail submission port, you're
connecting to a mail service that has the responsibility not to let
spam escape, and your ISP has done its job of stopping point-source
pollution.


>Bill>I've got a strong preference for ISPs to run a
>Bill>Block-25-by-default/Enable-when-asked.  [...]

> This is, of course, exactly why this blocking is done.

It looks like you're missing half my point, which is the Enable-when-asked part.
There are users who are perfectly legitimately running MTAs at home,
whether for reliability or privacy (e.g. so they can run SMTP-over-TLS
end-to-end) or just simplicity, and ISPs shouldn't be blocking them
(unless they're spammers, of course.)

> My take on this is that it IS best practice to have users use the submission 
> port (587) for mail submission from the MUA to an MTA.
If you're running an MTA service, then yes.  If you're running a
transport service, then not necessarily.


-- 

             Thanks;     Bill

Note that this isn't my regular email account - It's still experimental so far.
And Google probably logs and indexes everything you send it.



Re: Outgoing SMTP Servers

2011-11-01 Thread Carlos Martinez-Cagnazzo
The point to make here is:

- if an ISP takes the path of blocking tcp/25, then they MUST
communicate this appropiately to customers and other users
- they also MUST provide alternatives: SMTP over SSL should be allowed
(tcp/465), authenticated relay, but *something*.

IMO blocking 25/tcp is a side-effect of the failure of the whole ISP
system to decisively deal with spammers. It's easier to blind-block
25/tcp than to do proper investigations and to collaborate with law
enforcement. I have tried to hand reports with *static* IP addresses,
contract identifiers and even home, mobile and work phone numbers of
known spammers in Uruguay (I happen to have my personal feud with one
that sells dog food), only to be shelved by management on the fears of
legal action.

I have also trouble swallowing the argument of "blocking 25/tcp is
great because it avoids us getting into black lists and reduces spam".
Yes, sure, but that doesn't prove it's the right approach in the long
run, as you are dealing with symptoms and not causes/sources.

It's the same thing as having tons of aspirines each time you have a
headache. Even if the pain subsides, you might still have other
underlying conditions that in fact are being masqueraded by your
"solution".

So, as it is often the case in society, we all pay the price.



On Mon, Oct 31, 2011 at 11:17 PM, Brian Johnson  wrote:
>
>
> Sent from my iPad
>
> On Oct 31, 2011, at 4:17 PM, "Robert Bonomi" 
>
> 
>
>> There is an at-least-somewhat-valid argument against outbound filtering.
>> to wit, various receiving systems may have different policies on what is/
>> is-not 'acceptable' traffic.  They have a better idea of what is acceptable
>> to the recipients (their users), than the originating MTA operator does. An
>> originating system cannot accomodate that diversity of opinions _without_
>> getting input from all prospective recipients.
>>
>> And it is, of course, 'not practical' for every email recipient to notify
>> every email 'source' network as to what that recpient considers 'acceptable'.
>> 
>
> This is not plausible. It also has nothing to do with a network owner 
> protecting his network from his own users.
>
>>
>> There are only a relative handful of things a _residential_ provider can
>> use to "reliably" filter outgoing mail. A non-comprehensive list:
>>  1) 'Greylisting' at the origin is as effective at stopping spam as it is
>>     at the destination.
>>  2) Checks for certain kinds of standards violations that legitimate mail
>>     software does not make.
>>  3) Check for certain kinds of 'lies' in headers -- things that *cannot*
>>     occur in legitimate email.
>>  4) 'Rate-limiting' to detect/quarrantine abnormal traffic levels.
>>  5) Tracking SMTP 'MAIL FROM:" and the "From:" (or 'Resent-From:', if
>>     present), and quarrantining on abnormal numbers of different putative
>>     origins.
>>
>> There's no point in checking source addresses against any DNSBL, for reasons
>> that should be 'obvious'.  <*GRIN*>
>>
>> Further, any sort of "content" filters prevent customers from _discussing_
>> scams in e-mail.
>>
>> There is a 'hard' problem in letting the source 'opt out' of such filtering,
>> because an intentional 'bad guy' will request his outgoing mail not be
>> monitored, as well as the person who has a 'legitimate' reason for sending
>> messages that might trip mindless content filters.
>>
>> Statistical note:  Out of the last roughly 6,000 pieces of spam seen here,
>> circa 2,700 were caught by checks 2), and 3) above, and another circa 2,600
>> were in character-sets not supported here.   Incidentally, spam volume, as
>> seen here, is running a bit _under_ 2/3 of all email, down from a peak of
>> over 95%.
>>
>
> This misses the point of the thread which is not filtering. It is port 25 
> blocking. Statistically all of he problems exist on TCP port 25. This is why 
> the filtering is largely effective.
>
> - Brian
>



-- 
--
=
Carlos M. Martinez-Cagnazzo
http://www.labs.lacnic.net
=



Re: Outgoing SMTP Servers

2011-10-31 Thread Jack Bates

On 10/31/2011 8:12 PM, Brian Johnson wrote:


Sent from my iPad

On Oct 31, 2011, at 1:30 PM, "Jack Bates"  wrote:



On 10/31/2011 11:48 AM, Michael Thomas wrote:

I've often wondered the same thing as to what the resistance is to outbound
filtering is. I can think of a few possibilities:

1) cost of filtering
2) false positives
3) really _not_ wanting to know about abuse

On the other hand, you have

1) cost of tracking
2) support costs handling infections

It's really an range from "easiest and cost effective" to "doing it right". I 
personally run hybrid. There are areas that are near impossible to track; this is especially true 
for wide area wireless/cellular/NAT areas. I always recommend my customers block tcp/25, even to 
the local smarthosts. Use 587 and authentication to support better tracking. It's a hack, though, 
as it doesn't stop other abuses and it won't fix the underlying root cause.

Let me know when u can "fix" the root causes. The two I know of:
1. Bad actors
2. Clueless users

While true, from a security viewpoint, the root cause is loss of control 
over the system involved. Spam, while perhaps the most visible and 
annoying to others is not my highest concern (We find the number of 
clueless users direct spamming is miniscule compared to hijacked 
systems). My concern is that the customer has lost control of their 
machine and could at that moment be unknowingly giving out critical 
information.


-Jack



RE: Outgoing SMTP Servers

2011-10-31 Thread Keith Medcalf


Dave CROCKER [mailto:d...@dcrocker.net] said on Sunday, 30 October, 2011 22:41

> On 10/30/2011 8:36 PM, Brian Johnson wrote:
>> So you support filtering end-user outbound SMTP sessions as this is a
>> means to prevent misuse of the Commons*. Correct?

> If it is acceptable to have the receiving SMTP server at one end of a
> connection do filtering -- and it is -- then why wouldn't it be acceptable to 
> have
> filtering done at the source end of that SMTP connection?

> As soon as we step upstream this way, stepping up earlier still is merely
> a question of efficacy and efficiency.

Actually, if it is my network I have the absolute right to control what comes 
in and what goes out.  If I am a commercial entity and my paying customers like 
this, then I will make lots of money.  If they don't, I will go out of 
business.  Thus for self-interest and survival end-user-networks do not 
restrict outbound excessively but block inbound with various policies that 
strike a balance between paying customers going elsewhere and paying customers 
leaving for less controlled environments, while still making a profit and 
staying in business.

Hence, we end up with the situation that we have.  It won't change without 
either (a) every operator deciding to do the same thing for their own 
collective best interest (such as blocking outbound TCP/25); or, (b) external 
fascist forces.

And the bit-movers really don't care, since all they do is move bits...and more 
bits means more money.








Re: Outgoing SMTP Servers

2011-10-31 Thread Brian Johnson


Sent from my iPad

On Oct 31, 2011, at 4:17 PM, "Robert Bonomi"  



> There is an at-least-somewhat-valid argument against outbound filtering.
> to wit, various receiving systems may have different policies on what is/
> is-not 'acceptable' traffic.  They have a better idea of what is acceptable
> to the recipients (their users), than the originating MTA operator does. An
> originating system cannot accomodate that diversity of opinions _without_ 
> getting input from all prospective recipients.
> 
> And it is, of course, 'not practical' for every email recipient to notify 
> every email 'source' network as to what that recpient considers 'acceptable'.
> 

This is not plausible. It also has nothing to do with a network owner 
protecting his network from his own users.

> 
> There are only a relative handful of things a _residential_ provider can 
> use to "reliably" filter outgoing mail. A non-comprehensive list:
>  1) 'Greylisting' at the origin is as effective at stopping spam as it is
> at the destination.
>  2) Checks for certain kinds of standards violations that legitimate mail 
> software does not make.
>  3) Check for certain kinds of 'lies' in headers -- things that *cannot*
> occur in legitimate email. 
>  4) 'Rate-limiting' to detect/quarrantine abnormal traffic levels.
>  5) Tracking SMTP 'MAIL FROM:" and the "From:" (or 'Resent-From:', if
> present), and quarrantining on abnormal numbers of different putative
> origins.
> 
> There's no point in checking source addresses against any DNSBL, for reasons
> that should be 'obvious'.  <*GRIN*>
> 
> Further, any sort of "content" filters prevent customers from _discussing_ 
> scams in e-mail.
> 
> There is a 'hard' problem in letting the source 'opt out' of such filtering,
> because an intentional 'bad guy' will request his outgoing mail not be 
> monitored, as well as the person who has a 'legitimate' reason for sending
> messages that might trip mindless content filters.
> 
> Statistical note:  Out of the last roughly 6,000 pieces of spam seen here,
> circa 2,700 were caught by checks 2), and 3) above, and another circa 2,600
> were in character-sets not supported here.   Incidentally, spam volume, as
> seen here, is running a bit _under_ 2/3 of all email, down from a peak of 
> over 95%.
> 

This misses the point of the thread which is not filtering. It is port 25 
blocking. Statistically all of he problems exist on TCP port 25. This is why 
the filtering is largely effective.

- Brian


Re: Outgoing SMTP Servers

2011-10-31 Thread Brian Johnson


Sent from my iPad

On Oct 31, 2011, at 1:30 PM, "Jack Bates"  wrote:

> 
> 
> On 10/31/2011 11:48 AM, Michael Thomas wrote:
>> I've often wondered the same thing as to what the resistance is to outbound
>> filtering is. I can think of a few possibilities:
>> 
>> 1) cost of filtering
>> 2) false positives
>> 3) really _not_ wanting to know about abuse
> 
> On the other hand, you have
> 
> 1) cost of tracking
> 2) support costs handling infections
> 
> It's really an range from "easiest and cost effective" to "doing it right". I 
> personally run hybrid. There are areas that are near impossible to track; 
> this is especially true for wide area wireless/cellular/NAT areas. I always 
> recommend my customers block tcp/25, even to the local smarthosts. Use 587 
> and authentication to support better tracking. It's a hack, though, as it 
> doesn't stop other abuses and it won't fix the underlying root cause.

Let me know when u can "fix" the root causes. The two I know of:
1. Bad actors
2. Clueless users

> 
> In locations that support ease of tracking, using a mixture of feedback loops 
> with proper support is usually the proper way. This allows notification and 
> fixing of the root cause. In our case, we recommend quick suspensions to 
> demonstrate to customer how seriously we take the problem, and then we point 
> out that the sending of spam/scanning is only the easier to detect symptoms. 
> It is unlikely we'll notice if they have a keylogger as well.

Still not the real root cause, but close. ;)

Largely in agreement otherwise.

 - Brian


Re: Outgoing SMTP Servers

2011-10-31 Thread Robert Bonomi

On: Mon, 31 Oct 2011 09:48:21 -0700, Michael Thomas  opined:
>
> Dave CROCKER wrote:
> > 
> > 
> > On 10/30/2011 8:36 PM, Brian Johnson wrote:
> >> So you support filtering end-user outbound SMTP sessions as this is a 
> >> means to prevent misuse of the Commons*. Correct?
> > 
> > 
> > If it is acceptable to have the receiving SMTP server at one end of a 
> > connection do filtering -- and it is -- then why wouldn't it be 
> > acceptable to have filtering done at the source end of that SMTP 
> > connection?
> > 
> > As soon as we step upstream this way, stepping up earlier still is 
> > merely a question of efficacy and efficiency.
>
> I've often wondered the same thing as to what the resistance is to outbound
> filtering is. I can think of a few possibilities:
>
> 1) cost of filtering
> 2) false positives
> 3) really _not_ wanting to know about abuse
>
> Given the cost of incoming filtering, I'd think that outbound filtering 
> would be down in the noise. On the other hand, getting support blowback 
> for false positives seems plausible, but probably no worse than blowback 
> from false positives incoming.  So, #3 -- assuming my list is exhaustive 
> which it probably isn't -- seems like a real possibility. Especially when 
> you consider that it opens a can of worms of "now that > we know we have 
> a likely bot, what do we with it, and how much will that cost?"

There is an at-least-somewhat-valid argument against outbound filtering.
to wit, various receiving systems may have different policies on what is/
is-not 'acceptable' traffic.  They have a better idea of what is acceptable
to the recipients (their users), than the originating MTA operator does. An
originating system cannot accomodate that diversity of opinions _without_ 
getting input from all prospective recipients.

And it is, of course, 'not practical' for every email recipient to notify 
every email 'source' network as to what that recpient considers 'acceptable'.


There are only a relative handful of things a _residential_ provider can 
use to "reliably" filter outgoing mail. A non-comprehensive list:
  1) 'Greylisting' at the origin is as effective at stopping spam as it is
 at the destination.
  2) Checks for certain kinds of standards violations that legitimate mail 
 software does not make.
  3) Check for certain kinds of 'lies' in headers -- things that *cannot*
 occur in legitimate email. 
  4) 'Rate-limiting' to detect/quarrantine abnormal traffic levels.
  5) Tracking SMTP 'MAIL FROM:" and the "From:" (or 'Resent-From:', if
 present), and quarrantining on abnormal numbers of different putative
 origins.

There's no point in checking source addresses against any DNSBL, for reasons
that should be 'obvious'.  <*GRIN*>

Further, any sort of "content" filters prevent customers from _discussing_ 
scams in e-mail.

There is a 'hard' problem in letting the source 'opt out' of such filtering,
because an intentional 'bad guy' will request his outgoing mail not be 
monitored, as well as the person who has a 'legitimate' reason for sending
messages that might trip mindless content filters.

Statistical note:  Out of the last roughly 6,000 pieces of spam seen here,
circa 2,700 were caught by checks 2), and 3) above, and another circa 2,600
were in character-sets not supported here.   Incidentally, spam volume, as
seen here, is running a bit _under_ 2/3 of all email, down from a peak of 
over 95%.






Re: Outgoing SMTP Servers

2011-10-31 Thread Jack Bates



On 10/31/2011 11:48 AM, Michael Thomas wrote:

I've often wondered the same thing as to what the resistance is to outbound
filtering is. I can think of a few possibilities:

1) cost of filtering
2) false positives
3) really _not_ wanting to know about abuse


On the other hand, you have

1) cost of tracking
2) support costs handling infections

It's really an range from "easiest and cost effective" to "doing it 
right". I personally run hybrid. There are areas that are near 
impossible to track; this is especially true for wide area 
wireless/cellular/NAT areas. I always recommend my customers block 
tcp/25, even to the local smarthosts. Use 587 and authentication to 
support better tracking. It's a hack, though, as it doesn't stop other 
abuses and it won't fix the underlying root cause.


In locations that support ease of tracking, using a mixture of feedback 
loops with proper support is usually the proper way. This allows 
notification and fixing of the root cause. In our case, we recommend 
quick suspensions to demonstrate to customer how seriously we take the 
problem, and then we point out that the sending of spam/scanning is only 
the easier to detect symptoms. It is unlikely we'll notice if they have 
a keylogger as well.


Finally, when architecture allows it, dynamic profiles with ACL support 
allowing a default of tcp/25 blocked, and easy to find and click removal 
of an account from tcp/25 blocking, combined with ACL monitoring, 
flagging, and notification by support staff is probably the ultimate in 
ideal scenarios. Combined with a % of traffic mirrored into a tunnel to 
an IDS which monitors for things such as network scanning or known 
signatures outbound, it makes for a very effective mechanism to assist 
customers in protecting themselves.


I'm personally curious how much traffic is necessary to mirror to 
properly detect problems. ie, can you get away with 1% or less (GE for 
each 100GE-200GE of traffic) or if you must cover as much as 10%+. My 
traffic load is small enough that it doesn't matter, but it's always 
nice to know how well something might scale.



Jack



Re: Outgoing SMTP Servers

2011-10-31 Thread Michael Thomas

Dave CROCKER wrote:



On 10/30/2011 8:36 PM, Brian Johnson wrote:
So you support filtering end-user outbound SMTP sessions as this is a 
means to prevent misuse of the Commons*. Correct?



If it is acceptable to have the receiving SMTP server at one end of a 
connection do filtering -- and it is -- then why wouldn't it be 
acceptable to have filtering done at the source end of that SMTP 
connection?


As soon as we step upstream this way, stepping up earlier still is 
merely a question of efficacy and efficiency.


I've often wondered the same thing as to what the resistance is to outbound
filtering is. I can think of a few possibilities:

1) cost of filtering
2) false positives
3) really _not_ wanting to know about abuse

Given the cost of incoming filtering, I'd think that outbound filtering would be
down in the noise. On the other hand, getting support blowback for false 
positives
seems plausible, but probably no worse than blowback from false positives 
incoming.
So, #3 -- assuming my list is exhaustive which it probably isn't -- seems like 
a real
possibility. Especially when you consider that it opens a can of worms of "now 
that
we know we have a likely bot, what do we with it, and how much will that cost?"

Mike



RE: Outgoing SMTP Servers

2011-10-31 Thread Brian Johnson
Bill,

Responses in-line...

>-Original Message-
>From: Bill Stewart [mailto:nonobvi...@gmail.com]
>Sent: Friday, October 28, 2011 6:22 PM
>To: nanog@nanog.org
>Cc: Brian Johnson
>Subject: Re: Outgoing SMTP Servers
>



>
>I've got a strong preference for ISPs to run a
>Block-25-by-default/Enable-when-asked.  As a purist, I'd prefer to
>have Internet connections that are actually Internet connections, and
>if you want to run email on a Linux box at home or have an Arduino in
>your refrigerator email the grocery when you're out of milk, you
>should be able to, and if some meddling kid at an ISP wants to block
>it, they should get off your lawn.  In practice, of course, somewhere
>between 99.9% and 99.999% of all home MTAs aren't Linux boxes or Macs,
>they're zombie spambots on home PCs, or occasional driveby wifi
>spammers or other pests, and not only should outgoing mail be blocked,
>but the user should be notified and the connection should probably be
>put into some kind of quarantined access.
>

This is, of course, exactly why this blocking is done.

>But that's for Port 25 - the Port 25 blocking by ISPs has largely
>pushed Email Service Providers to use other protocols such as 587 for
>mail submission from an MUA to the MTA, or webmail instead, and it's
>really bad practice for ISPs to interfere with that.  In some cases
>they'll still be sending spam, but that's the MTA's job to filter out,
>and if they don't, they'll end up on a bunch of RBLs.  (And generally
>they'll be trying to keep their mail clean themselves - if the MTA
>providers were spammers, they wouldn't need to go to the trouble of
>having actual residential users as customers when they could
>mass-produce it cheaper directly.)

For clarity it's really bad for ISPs to block ports other than 25 for the 
purposes of mail flow control... correct?

I would not block submission ports, specifically 587. More specifically, the 
only port I will block would be 25. The RFC actually says to use the submission 
port  for the MUA to MTA anyways. RFC 5068 is definitive on this issue. Also 
read RFC 4409 and its predecessors.

My take on this is that it IS best practice to have users use the submission 
port (587) for mail submission from the MUA to an MTA.

Call me a liar! :) 

- Brian




Re: Outgoing SMTP Servers

2011-10-30 Thread Dave CROCKER



On 10/30/2011 8:36 PM, Brian Johnson wrote:

So you support filtering end-user outbound SMTP sessions as this is a means to 
prevent misuse of the Commons*. Correct?



If it is acceptable to have the receiving SMTP server at one end of a connection 
do filtering -- and it is -- then why wouldn't it be acceptable to have 
filtering done at the source end of that SMTP connection?


As soon as we step upstream this way, stepping up earlier still is merely a 
question of efficacy and efficiency.


d/
--

  Dave Crocker
  Brandenburg InternetWorking
  bbiw.net



Re: Outgoing SMTP Servers

2011-10-30 Thread Brian Johnson

On Oct 30, 2011, at 2:19 PM, Dave CROCKER wrote:



> 
> Email travels over shared resources.  Spam consumes roughly %95 percent of 
> that shared path (comm lines and servers).  Receiving operators must devote 
> masses of resources to filter that firehose of mostly junk, in order to get 
> everyone's mailboxes to remain at least somewhat useful. Since the spammers 
> are well-organized and aggressive and often quite bright, they adapt their 
> attacks to get round these filters, thereby creating an extremely unstable 
> arms race. This means the entire situation is extremely unstable.  When -- 
> not if -- it breaks, mail becomes unusable.  That will be a common suffering.
> 
> The one-to-one cost or damage is probably also a reasonable perspective, but 
> it's /incremental/ to the shared cost.
> 
> d/
> -- 
> 
>  Dave Crocker
>  Brandenburg InternetWorking
>  bbiw.net
> 


So you support filtering end-user outbound SMTP sessions as this is a means to 
prevent misuse of the Commons*. Correct?

 - Brian

* I do not think of the Internet as a commons, but Dave does. I will not 
comment on this as it is tangential to the thread.


Re: Outgoing SMTP Servers

2011-10-30 Thread William Herrin
On Sun, Oct 30, 2011 at 3:17 PM, Dave CROCKER  wrote:
> Your misunderstanding of physical pollution pollutes your understanding of
> spam.  But it turns out that you seem to misunderstand spam quite a bit,
> independently.

Okay wise guy. Let's take another look at your version of email spam
as pollution.


Put some gangbangers in a truck and drive them down the street. These
are our allegorical spammers. As the truck rolls they fire thousands
of rounds, clip after clip, from Uzis aimed at every glass window that
they see.

Clearly I am mistaken to describe these gangbangers as mass murdering
criminals. When I say that they and the folks who aided and abetted
their spree should be locked away, I display my ignorance as to the
nature of gangs.

No, this is all really a matter of lead pollution: People taking too
much advantage of the fact that it's generally OK to drive on the
road, or throw objects through the air, a real tragedy of those
commons. It's not like we can jail everybody who decides to shoot up a
house. So, instead of hiring sheriffs whose our ire will land on folks
who willfully or negligently shielded the gangbangers from detection
and pursuit, we should forgive the complicit and restrict our efforts
to bulletproof glass and generally reducing the rain of bullets to a
more survivable level.

Regards,
Bill Herrin


-- 
William D. Herrin  her...@dirtside.com  b...@herrin.us
3005 Crane Dr. .. Web: 
Falls Church, VA 22042-3004



Re: Outgoing SMTP Servers

2011-10-30 Thread Dave CROCKER

Bill,


Your misunderstanding of physical pollution pollutes your understanding of spam. 
 But it turns out that you seem to misunderstand spam quite a bit, independently.


On 10/27/2011 9:26 PM, William Herrin wrote:

If you throw pollution into the air, it may eventually impact me or it
may blow somewhere else. Mostly it'll blow somewhere else. But as lots
of people throw pollution into the air, some non-trivial portion of
that pollution will drift over me. This is the so-called tragedy.


They used to be able to tell how recently someone moved to in Los Angeles by how 
corrupted their lungs were, from the /local/ pollution.  Maybe it's still 
possible.  Pollution tends to increase the occurrence of some diseases, thereby 
significantly increasing societal health costs. So the casual view of pollution 
going "somewhere else" is simply wrong.  Still you do seem to understand that it 
affects some mass of folk.




By contrast, if you send me spam email, you are directly abusing my
computer. The linkage is not at all amorphous. You send to me. I
receive from you. There is no "all world" or "local area" destination.
If you send without some specific pointer in my direction, I won't
receive it. Ever.

Imagining spam as a tragedy of the commons disguises its true nature
as a massive quantity of one-on-one abuses of individual owners'
computers. Worse, it forgives the owners of the intermediate networks
for shrugging their shoulders and turning a blind eye to the abusers.



Email travels over shared resources.  Spam consumes roughly %95 percent of that 
shared path (comm lines and servers).  Receiving operators must devote masses of 
resources to filter that firehose of mostly junk, in order to get everyone's 
mailboxes to remain at least somewhat useful. Since the spammers are 
well-organized and aggressive and often quite bright, they adapt their attacks 
to get round these filters, thereby creating an extremely unstable arms race. 
This means the entire situation is extremely unstable.  When -- not if -- it 
breaks, mail becomes unusable.  That will be a common suffering.


The one-to-one cost or damage is probably also a reasonable perspective, but 
it's /incremental/ to the shared cost.


d/
--

  Dave Crocker
  Brandenburg InternetWorking
  bbiw.net



Re: Outgoing SMTP Servers

2011-10-30 Thread Jay Ashworth
- Original Message -
> From: "Valdis Kletnieks" 

> On Thu, 27 Oct 2011 18:17:22 -, Brian Johnson said:
> > So... I'm in complete agreement with your statement, but The
> > Wikipedia reference is not pertinent.
> 
> So I point out the tragedy of the commons, you agree with it, but the 
> Wikipedia
> reference that talks about the same exact thing isn't pertinent? How does that
> follow? :)

http://xkcd.com/958/

Cheers,
-- jra
-- 
Jay R. Ashworth  Baylink   j...@baylink.com
Designer The Things I Think   RFC 2100
Ashworth & Associates http://baylink.pitas.com 2000 Land Rover DII
St Petersburg FL USA  http://photo.imageinc.us +1 727 647 1274



Re: Outgoing SMTP Servers

2011-10-28 Thread Brian Johnson
++1

- Brian

Sent from my iPad

On Oct 28, 2011, at 2:05 PM, "Mike Jones"  wrote:

> On 28 October 2011 16:41,   wrote:
>> You *do* realize that for all your nice "Thei Internet Is Not A Commons"
>> ranting, the basic problem is that some people (we'll call them spammers) 
>> *do*
>> think that (a) it's a commons (or at least the exact ownership of a given
>> chunk is irrelevant), and (b) they're allowed to graze their sheep upon it.
> 
> If someone keeps putting their animals in my garden then some
> countries would permit me to shoot them and sue the owner for the cost
> of the bullets. Even those with more restrictive property rights laws
> would still permit me to throw them off of my land and sue the owner
> for any damage they caused me.
> 
> On the Internet when people start shooting their sheep they think they
> are the victims and go to the dutch police, sorry i mean the police of
> whichever jurisdiction the hypothetical entity is from, complaining
> that they are being deprived of their right to abuse peoples gardens.
> 
> - Mike
> 



Re: Outgoing SMTP Servers

2011-10-28 Thread Brian Johnson


Sent from my iPad

On Oct 28, 2011, at 2:56 PM, "Owen DeLong"  wrote:

> 
> 
> Sent from my iPhone
> 
> On Oct 28, 2011, at 12:16, Brian Johnson  wrote:
> 
>> Owen,
>> 
>> When you stretch an analogy this thin, it always falls apart. I was 
>> referring to the poison/pollution not the water/air. A drought/vacuum* would 
>> not be possible, but would you want the poisoned water/air?
>> 
> I can tolerate a lot of spam if my legitimate messages get through. I have 
> zero tolerance for blocking my legitimate traffic in the name of stopping 
> pollution. I oppose the death penalty on the same basis. 
> 
> Owen
> 

How could my filter stop you from sending legitimate traffic? If you pay for 
services from me under my AUP, you need to comply with the AUP.

I think this is a dead topic. We simply disagree on the merits.

I appreciate your insight.

- Brian




Re: Outgoing SMTP Servers

2011-10-28 Thread Bill Stewart
There are several models for where the MTA lives in an ISP environment
- MTA at customer, connects to destination via Port 25.
- MUA at customer, MTA at ISP, connects to destination via Port 25.
- MTA at customer, ISP transparently forces connection through ISP
MTA, then connects to destination via 25
- MUA at customer, ISP, MTA at email service provider, connects to
destination via port 25.

The MUA-vs-MTA distinction and the MTA-at-ISP model are
_historical_artifacts_, left over from the days of dial ISPs.
- An MTA benefits from having a reliable full-time connection to the
Internet, because it's going to deliver mail to a potentially
unreliable destination and may need to keep trying repeatedly over a
long time, while the MUA only needs to connect to the MTA long enough
to pass the message.
- It's also helpful for the MTA to be colocated with the sender's
mailbox service, and the mailbox service and its domain names also
benefit from fulltime connectivity.
- While dial internet is almost dead, smartphones and wireless laptops
are partially recreating the unreliably-connected computer system, but
they usually use MTAs at an email service provider, not the ISP.
- On the other hand, any desktop computer or laptop, most smartphones,
and many wristwatches have far more computing horsepower and disk
space than the VAX 11/780s that ran early sendmail systems, so they're
perfectly capable of being first-class objects on the Internet and
running MTAs.

I've got a strong preference for ISPs to run a
Block-25-by-default/Enable-when-asked.  As a purist, I'd prefer to
have Internet connections that are actually Internet connections, and
if you want to run email on a Linux box at home or have an Arduino in
your refrigerator email the grocery when you're out of milk, you
should be able to, and if some meddling kid at an ISP wants to block
it, they should get off your lawn.  In practice, of course, somewhere
between 99.9% and 99.999% of all home MTAs aren't Linux boxes or Macs,
they're zombie spambots on home PCs, or occasional driveby wifi
spammers or other pests, and not only should outgoing mail be blocked,
but the user should be notified and the connection should probably be
put into some kind of quarantined access.

But that's for Port 25 - the Port 25 blocking by ISPs has largely
pushed Email Service Providers to use other protocols such as 587 for
mail submission from an MUA to the MTA, or webmail instead, and it's
really bad practice for ISPs to interfere with that.  In some cases
they'll still be sending spam, but that's the MTA's job to filter out,
and if they don't, they'll end up on a bunch of RBLs.  (And generally
they'll be trying to keep their mail clean themselves - if the MTA
providers were spammers, they wouldn't need to go to the trouble of
having actual residential users as customers when they could
mass-produce it cheaper directly.)



Re: Outgoing SMTP Servers

2011-10-28 Thread Owen DeLong


Sent from my iPhone

On Oct 28, 2011, at 12:16, Brian Johnson  wrote:

> Owen,
> 
> When you stretch an analogy this thin, it always falls apart. I was referring 
> to the poison/pollution not the water/air. A drought/vacuum* would not be 
> possible, but would you want the poisoned water/air?
> 
I can tolerate a lot of spam if my legitimate messages get through. I have zero 
tolerance for blocking my legitimate traffic in the name of stopping pollution. 
I oppose the death penalty on the same basis. 

Owen

> This analogy is bad enough without the nits picked out. I actually mixed two 
> posts to create a stream analogy out of an air analogy.
> 
> I will not go any further and all further follows on to this analogy should 
> be ignored. :)
> 
> - Brian J.
> 
> * a lack of air (for a reasonable deffinition of air) would be a vacuum... 
> right?
> 
>> -Original Message-
>> From: Owen DeLong [mailto:o...@delong.com]
>> Sent: Friday, October 28, 2011 12:11 PM
>> To: Brian Johnson
>> Subject: Re: Outgoing SMTP Servers
>> 
>>> 
>>>>> Nor is the data transiting these networks a commons. The air over my
>>>>> land is a commons. I don't control it. If I pollute it or if I don't,
>>>>> it promptly travels over someone else's land.
>>>> 
>>>> If you choose to pollute the air heavily, the value of the air drops for
>>>> everybody.
>>>> If you choose to pollute the Net heavily, the value of the Net drops for
>>>> everybody.
>>>> 
>>> 
>>> STRIKE 3! Oops got ahead of myself.
>>> 
>>> I'm attempting to prevent the pollution but I may capture a little good 
>>> water
>> (almost nothing) along the way. To say that this is a way of "bad acting" and
>> causes a loss of value to the Internet as a whole is pure folly.
>>> 
>> 
>> No, it really isn't. Because the good water that you are catching is actually
>> causing
>> a drought downstream.
>> 
>> Owen
> 



Re: Outgoing SMTP Servers

2011-10-28 Thread Jay Ashworth
- Original Message -
> From: "William Herrin" 

> Interesting. I want to abstract and restate what I think you just said
> and ask you to correct my understanding:
> 
> Making a service accessible to the public via the Internet implicitly
> grants some basic permission to that public to make use of the
> service, permission which can not be revoked solely by saying so.

That's correct; did you think it wasn't?

The offer is *in the presence of a standard service on a standard port*; if I 
put a SMTP receiver on tcp/25, you are, yes, implicitly permitted to try to 
use it to send me email.

There *is no place* to put "saying permission is revoked", so where 
would someone look, even if their daemon wanted to look.

> If that's the case, what is the common denominator? What is the
> standard of permission automatically granted by placing an email
> server on the internet, from which a particular operator may grant
> more permission but may not reasonably grant less? Put another way,
> what's the whitelist of activities for which we generally expect our
> vendor to ignore complaints, what's the blacklist of activities for
> which a vendor who fails to adequately redress complaints is
> misbehaving and what's left in the gray zone where behavior might be
> abusive but is not automatically so?

If there are specific things you want people not to do, *make it impossible
for them to do those things* (ssh authentication, for example).

Above that, I suppose that rate limiting failures is expected of a connecting
client...

Cheers,
-- jra
-- 
Jay R. Ashworth  Baylink   j...@baylink.com
Designer The Things I Think   RFC 2100
Ashworth & Associates http://baylink.pitas.com 2000 Land Rover DII
St Petersburg FL USA  http://photo.imageinc.us +1 727 647 1274



Re: Outgoing SMTP Servers

2011-10-28 Thread Mike Jones
On 28 October 2011 16:41,   wrote:
> You *do* realize that for all your nice "Thei Internet Is Not A Commons"
> ranting, the basic problem is that some people (we'll call them spammers) *do*
> think that (a) it's a commons (or at least the exact ownership of a given
> chunk is irrelevant), and (b) they're allowed to graze their sheep upon it.

If someone keeps putting their animals in my garden then some
countries would permit me to shoot them and sue the owner for the cost
of the bullets. Even those with more restrictive property rights laws
would still permit me to throw them off of my land and sue the owner
for any damage they caused me.

On the Internet when people start shooting their sheep they think they
are the victims and go to the dutch police, sorry i mean the police of
whichever jurisdiction the hypothetical entity is from, complaining
that they are being deprived of their right to abuse peoples gardens.

- Mike



Re: Outgoing SMTP Servers

2011-10-28 Thread William Herrin
On Fri, Oct 28, 2011 at 11:41 AM,   wrote:
> On Thu, 27 Oct 2011 23:44:16 EDT, William Herrin said:
>> For our purpose, describing the Internet as a commons fundamentally
>> misunderstands its nature.
>
> You *do* realize that for all your nice "Thei Internet Is Not A Commons"
> ranting, the basic problem is that some people (we'll call them spammers) *do*
> think that (a) it's a commons (or at least the exact ownership of a given
> chunk is irrelevant), and (b) they're allowed to graze their sheep upon it.

Squatters, trespassers and thieves always manage to find self-serving
justifications for their behavior. The theory that it's OK to take
from the faceless owner is not a new one, nor is it particularly
related to the concept of a commons.


>> The point is, at every step with the Internet there is always a
>> specific owner whose property is either being used with his permission
>> or abused against his wishes. At no point is it a commons.
>
> Try working the same example but using a stream flowing across your property
> instead, that feeds into the reservior the municipal water supply draws from.
> Yes, you own your section of the stream, and the guy next door owns his
> section, and so on.  So the stream is not a commons - but the quality of the
> water in it *is*.

You've picked an interesting analogy for the flow of data on the Internet.

If I dam up the stream on my side inducing my upstream neighbor's
property to flood, I can be sued and I *will* lose the lawsuit. My
action has willfully and directly damaged his property. Same if I
divert all the water and dry out my downstream neighbor's lake.

In more populous areas this sort of issue becomes sufficiently
contentious that the government simply takes the stream, defining it
as a "stormwater easement" and at that point, a regulated commons.

My house is sandwiched between a stormwater easement under the back
yard and a sanitary sewer easement under the front. I know far more
about the legal issues around moving water than I ever wanted to. Like
the fact that an areaway drain built in the 50's was typically
attached to the sanitary sewer in full compliance with the building
code, but the current building code forbids it and a judge will throw
the book at you even though post-ex-facto normally applies to old
construction.

Regards,
Bill Herrin

-- 
William D. Herrin  her...@dirtside.com  b...@herrin.us
3005 Crane Dr. .. Web: 
Falls Church, VA 22042-3004



Re: Outgoing SMTP Servers

2011-10-28 Thread -Hammer-

Girls,
You are all pretty. End the thread. Seriously.

-Hammer-

"I was a normal American nerd"
-Jack Herer



On 10/28/2011 01:59 PM, William Herrin wrote:

On Fri, Oct 28, 2011 at 1:34 AM, Joel jaeggli  wrote:
   

Email as facility is a public good whether it constitutes a commons or
not... If wasn't you wouldn't bother putting up a server that would
accept unsolicited incoming connections on behalf of yourself and
others, doing so is generically non-rival and non-excludable although
not perfectly so in either case (what public good is).
 

Interesting. I want to abstract and restate what I think you just said
and ask you to correct my understanding:

Making a service accessible to the public via the Internet implicitly
grants some basic permission to that public to make use of the
service, permission which can not be revoked solely by saying so.


If that's the case, what is the common denominator? What is the
standard of permission automatically granted by placing an email
server on the internet, from which a particular operator may grant
more permission but may not reasonably grant less? Put another way,
what's the whitelist of activities for which we generally expect our
vendor to ignore complaints, what's the blacklist of activities for
which a vendor who fails to adequately redress complaints is
misbehaving and what's left in the gray zone where behavior might be
abusive but is not automatically so?

Regards,
Bill Herrin


   


Re: Outgoing SMTP Servers

2011-10-28 Thread William Herrin
On Fri, Oct 28, 2011 at 1:34 AM, Joel jaeggli  wrote:
> Email as facility is a public good whether it constitutes a commons or
> not... If wasn't you wouldn't bother putting up a server that would
> accept unsolicited incoming connections on behalf of yourself and
> others, doing so is generically non-rival and non-excludable although
> not perfectly so in either case (what public good is).

Interesting. I want to abstract and restate what I think you just said
and ask you to correct my understanding:

Making a service accessible to the public via the Internet implicitly
grants some basic permission to that public to make use of the
service, permission which can not be revoked solely by saying so.


If that's the case, what is the common denominator? What is the
standard of permission automatically granted by placing an email
server on the internet, from which a particular operator may grant
more permission but may not reasonably grant less? Put another way,
what's the whitelist of activities for which we generally expect our
vendor to ignore complaints, what's the blacklist of activities for
which a vendor who fails to adequately redress complaints is
misbehaving and what's left in the gray zone where behavior might be
abusive but is not automatically so?

Regards,
Bill Herrin


-- 
William D. Herrin  her...@dirtside.com  b...@herrin.us
3005 Crane Dr. .. Web: 
Falls Church, VA 22042-3004



RE: Outgoing SMTP Servers

2011-10-28 Thread Brian Johnson
Owen,

When you stretch an analogy this thin, it always falls apart. I was referring 
to the poison/pollution not the water/air. A drought/vacuum* would not be 
possible, but would you want the poisoned water/air?

This analogy is bad enough without the nits picked out. I actually mixed two 
posts to create a stream analogy out of an air analogy.

I will not go any further and all further follows on to this analogy should be 
ignored. :)

 - Brian J.

* a lack of air (for a reasonable deffinition of air) would be a vacuum... 
right?

>-Original Message-
>From: Owen DeLong [mailto:o...@delong.com]
>Sent: Friday, October 28, 2011 12:11 PM
>To: Brian Johnson
>Subject: Re: Outgoing SMTP Servers
>
>>
>>>> Nor is the data transiting these networks a commons. The air over my
>>>> land is a commons. I don't control it. If I pollute it or if I don't,
>>>> it promptly travels over someone else's land.
>>>
>>> If you choose to pollute the air heavily, the value of the air drops for
>>> everybody.
>>> If you choose to pollute the Net heavily, the value of the Net drops for
>>> everybody.
>>>
>>
>> STRIKE 3! Oops got ahead of myself.
>>
>> I'm attempting to prevent the pollution but I may capture a little good water
>(almost nothing) along the way. To say that this is a way of "bad acting" and
>causes a loss of value to the Internet as a whole is pure folly.
>>
>
>No, it really isn't. Because the good water that you are catching is actually
>causing
>a drought downstream.
>
>Owen




RE: Outgoing SMTP Servers

2011-10-28 Thread Brian Johnson
Comments in-line

>-Original Message-
>From: valdis.kletni...@vt.edu [mailto:valdis.kletni...@vt.edu]
>Sent: Friday, October 28, 2011 10:42 AM
>To: William Herrin
>Cc: nanog@nanog.org; Pete Carah
>Subject: Re: Outgoing SMTP Servers
>
>On Thu, 27 Oct 2011 23:44:16 EDT, William Herrin said:
>
>> For our purpose, describing the Internet as a commons fundamentally
>> misunderstands its nature.
>
>You *do* realize that for all your nice "Thei Internet Is Not A Commons"
>ranting, the basic problem is that some people (we'll call them spammers)
>*do*
>think that (a) it's a commons (or at least the exact ownership of a given
>chunk is irrelevant), and (b) they're allowed to graze their sheep upon it.

So we should treat the Internet with respect to bad actors differently than 
others. STRIKE 1!

>
>> The Internet is not jointly owned. You do not own a one seven
>> billionth share of the network in my basement and I do not a own one
>> seven billionth of yours. Rather, the Internet is a cooperative effort
>> of the sole owners of its distinct individual pieces.
>
>That's correct, as far as it goes.  However, what *is* a commons is the *value*
>of the cooperative effort - see Metcalf's Law.  You turn off or disconnect your
>share of the Internet, my share of the *value* of the Internet drops slightly.
>

So bad actors destroying the value created by a cooperative of good actors is 
not bad? STRIKE 2!

>> Nor is the data transiting these networks a commons. The air over my
>> land is a commons. I don't control it. If I pollute it or if I don't,
>> it promptly travels over someone else's land.
>
>If you choose to pollute the air heavily, the value of the air drops for
>everybody.
>If you choose to pollute the Net heavily, the value of the Net drops for
>everybody.
>

STRIKE 3! Oops got ahead of myself.

I'm attempting to prevent the pollution but I may capture a little good water 
(almost nothing) along the way. To say that this is a way of "bad acting" and 
causes a loss of value to the Internet as a whole is pure folly.

>> The point is, at every step with the Internet there is always a
>> specific owner whose property is either being used with his permission
>> or abused against his wishes. At no point is it a commons.
>
>Try working the same example but using a stream flowing across your
>property
>instead, that feeds into the reservior the municipal water supply draws from.
>Yes, you own your section of the stream, and the guy next door owns his
>section, and so on.  So the stream is not a commons - but the quality of the
>water in it *is*. (Yes, weak analogy, the downstream people have no say in it.
>Pretend for the sake of argument that everybody involved lives next to a
>stream
>that feeds the reservior that everybody drinks from - that's actually a pretty
>good match to the Internet topology).

Actually if there were 4 strikes... STRIKE 4!

Since I only transit destination packets, this analogy does not apply in any 
significant way. In fact this would only apply to transit providers filtering 
between peers or other transit connections. In my experience this is used at 
the customer connection to the transit or peering connection to protect the 
Internet from the clueless or compromised.

- Brian

BTW... what a great game last night! :)




Re: Outgoing SMTP Servers

2011-10-28 Thread Valdis . Kletnieks
On Thu, 27 Oct 2011 23:44:16 EDT, William Herrin said:

> For our purpose, describing the Internet as a commons fundamentally
> misunderstands its nature.

You *do* realize that for all your nice "Thei Internet Is Not A Commons"
ranting, the basic problem is that some people (we'll call them spammers) *do*
think that (a) it's a commons (or at least the exact ownership of a given
chunk is irrelevant), and (b) they're allowed to graze their sheep upon it.

> The Internet is not jointly owned. You do not own a one seven
> billionth share of the network in my basement and I do not a own one
> seven billionth of yours. Rather, the Internet is a cooperative effort
> of the sole owners of its distinct individual pieces.

That's correct, as far as it goes.  However, what *is* a commons is the *value*
of the cooperative effort - see Metcalf's Law.  You turn off or disconnect your
share of the Internet, my share of the *value* of the Internet drops slightly.

> Nor is the data transiting these networks a commons. The air over my
> land is a commons. I don't control it. If I pollute it or if I don't,
> it promptly travels over someone else's land.

If you choose to pollute the air heavily, the value of the air drops for 
everybody.
If you choose to pollute the Net heavily, the value of the Net drops for 
everybody.

> The point is, at every step with the Internet there is always a
> specific owner whose property is either being used with his permission
> or abused against his wishes. At no point is it a commons.

Try working the same example but using a stream flowing across your property
instead, that feeds into the reservior the municipal water supply draws from.
Yes, you own your section of the stream, and the guy next door owns his
section, and so on.  So the stream is not a commons - but the quality of the
water in it *is*. (Yes, weak analogy, the downstream people have no say in it.
Pretend for the sake of argument that everybody involved lives next to a stream
that feeds the reservior that everybody drinks from - that's actually a pretty
good match to the Internet topology).



pgpUvl0nGPXqZ.pgp
Description: PGP signature


RE: Outgoing SMTP Servers

2011-10-28 Thread McCall, Gabriel
The alternative to centralization is enclosure: segmentation and private 
ownership of portions of the formerly common resource. Since the internet is 
already thus enclosed, with each portion completely owned by one autonomous 
agent or another, the problem at hand is not a commons problem at all but 
merely one of negotiation and market force. Internet Death Penalties, 
blacklists, and unilateral de-peering and blackholing are exactly the sorts of 
responses an economist would expect to see to a rogue actor in the network 
community, precise analogs of various types of economic ostracism going back to 
the merchant consortia of the middle ages.

-Gabriel

-Original Message-
From: Pete Carah [mailto:p...@altadena.net] 
Sent: Thursday, October 27, 2011 9:29 PM
To: nanog@nanog.org
Subject: Re: Outgoing SMTP Servers

Maybe he is concerned that the Wikipedia article gets into nit-picking about 
the ownership of the commons that isn't relevant to our problem, and also is 
rather long-winded.  Hardin got into some things at the end of his paper that 
probably aren't either (but then, he was a population biologist and not an 
economist).  BTW - that paper is a good read and not too long.  The journal 
link (reference 1 in the wikipedia article) actually works openly (AAAS only 
blocks full access for a while...)

For our purpose, the ownership of the commons in question truly isn't relevant; 
the fundamental statement of the tragedy for us is that a "useful" resource 
that is incrementally free (or even cheap enough) to a large number of 
participants will get exploited and probably overused.

I'm not aware of any solution to this problem with commons that doesn't involve 
a central authority :-( In feudal practice the landlord could do some 
enforcement; the spanish alcaldes were another good example of a semi-central 
solution to the commons problem (water rights in their origins, though their 
authority grew over time).

Classic economics says that market pricing is the solution, but that tends to 
result in another kind of tragedy.

-- Pete

On 10/27/2011 05:38 PM, valdis.kletni...@vt.edu wrote:
> On Thu, 27 Oct 2011 18:17:22 -, Brian Johnson said:
>> So... I'm in complete agreement with your statement, but The 
>> Wikipedia
reference is not pertinent.
>
> So I point out the tragedy of the commons, you agree with it, but the
Wikipedia
> reference that talks about the same exact thing isn't pertinent? How
does that
> follow? :)






Re: Outgoing SMTP Servers

2011-10-27 Thread Joel jaeggli
Email as facility is a public good whether it constitutes a commons or
not... If wasn't you wouldn't bother putting up a server that would
accept unsolicited incoming connections on behalf of yourself and
others, doing so is generically non-rival and non-excludable although
not perfectly so in either case (what public good is).

On 10/27/11 21:26 , William Herrin wrote:
> On Thu, Oct 27, 2011 at 11:59 PM, Dave CROCKER  wrote:
>> On 10/28/2011 5:44 AM, William Herrin wrote:
>>> A commons is jointly owned, either by a non-trivial number of private
>>> owners or by all citizens of a government.
>>
>> The practical use of the term is a bit broader:
>>   
>>
>> As rule, the term gets applied to situations of fate-sharing when actions by
>> some affect utility for many.
>>
>> You cited air pollution.  The Internet can suffer comparable effects.
>>
>> Spam can reasonably be called pollution and it has a systemic effect on all
>> users.  For such an issue, it's reasonable and even helpful to view it as a
>> commons.
> 
> Dave,
> 
> I respectfully disagree.
> 
> If you throw pollution into the air, it may eventually impact me or it
> may blow somewhere else. Mostly it'll blow somewhere else. But as lots
> of people throw pollution into the air, some non-trivial portion of
> that pollution will drift over me. This is the so-called tragedy.
> 
> By contrast, if you send me spam email, you are directly abusing my
> computer. The linkage is not at all amorphous. You send to me. I
> receive from you. There is no "all world" or "local area" destination.
> If you send without some specific pointer in my direction, I won't
> receive it. Ever.
> 
> Imagining spam as a tragedy of the commons disguises its true nature
> as a massive quantity of one-on-one abuses of individual owners'
> computers. Worse, it forgives the owners of the intermediate networks
> for shrugging their shoulders and turning a blind eye to the abusers.
> 
> Regards,
> Bill Herrin
> 




Re: Outgoing SMTP Servers

2011-10-27 Thread William Herrin
On Thu, Oct 27, 2011 at 11:59 PM, Dave CROCKER  wrote:
> On 10/28/2011 5:44 AM, William Herrin wrote:
>> A commons is jointly owned, either by a non-trivial number of private
>> owners or by all citizens of a government.
>
> The practical use of the term is a bit broader:
>   
>
> As rule, the term gets applied to situations of fate-sharing when actions by
> some affect utility for many.
>
> You cited air pollution.  The Internet can suffer comparable effects.
>
> Spam can reasonably be called pollution and it has a systemic effect on all
> users.  For such an issue, it's reasonable and even helpful to view it as a
> commons.

Dave,

I respectfully disagree.

If you throw pollution into the air, it may eventually impact me or it
may blow somewhere else. Mostly it'll blow somewhere else. But as lots
of people throw pollution into the air, some non-trivial portion of
that pollution will drift over me. This is the so-called tragedy.

By contrast, if you send me spam email, you are directly abusing my
computer. The linkage is not at all amorphous. You send to me. I
receive from you. There is no "all world" or "local area" destination.
If you send without some specific pointer in my direction, I won't
receive it. Ever.

Imagining spam as a tragedy of the commons disguises its true nature
as a massive quantity of one-on-one abuses of individual owners'
computers. Worse, it forgives the owners of the intermediate networks
for shrugging their shoulders and turning a blind eye to the abusers.

Regards,
Bill Herrin

-- 
William D. Herrin  her...@dirtside.com  b...@herrin.us
3005 Crane Dr. .. Web: 
Falls Church, VA 22042-3004



Re: Outgoing SMTP Servers

2011-10-27 Thread Dave CROCKER



On 10/28/2011 5:44 AM, William Herrin wrote:

A commons is jointly owned, either by a non-trivial number of private
owners or by all citizens of a government.



The practical use of the term is a bit broader:

   

As rule, the term gets applied to situations of fate-sharing when actions by 
some affect utility for many.


You cited air pollution.  The Internet can suffer comparable effects.

Spam can reasonably be called pollution and it has a systemic effect on all 
users.  For such an issue, it's reasonable and even helpful to view it as a commons.


d/

--

  Dave Crocker
  Brandenburg InternetWorking
  bbiw.net



Re: Outgoing SMTP Servers

2011-10-27 Thread William Herrin
On Thu, Oct 27, 2011 at 9:29 PM, Pete Carah  wrote:
> On 10/27/2011 05:38 PM, valdis.kletni...@vt.edu wrote:
>> On Thu, 27 Oct 2011 18:17:22 -, Brian Johnson said:
>>> So... I'm in complete agreement with your statement, but The Wikipedia
> reference is not pertinent.
>
> For our purpose, the ownership of the commons in question truly isn't
> relevant;

Pete,

For our purpose, describing the Internet as a commons fundamentally
misunderstands its nature.

A commons is jointly owned, either by a non-trivial number of private
owners or by all citizens of a government. For example, I own a
3/11,000ths share of a private road network. Those roads are a
commons.

The Internet is not jointly owned. You do not own a one seven
billionth share of the network in my basement and I do not a own one
seven billionth of yours. Rather, the Internet is a cooperative effort
of the sole owners of its distinct individual pieces.

As the owner of the network in my basement, it is my privilege alone
to decide how you may and may not use it. The same goes for the
respective owners of every other piece of the Internet.

Nor is the data transiting these networks a commons. The air over my
land is a commons. I don't control it. If I pollute it or if I don't,
it promptly travels over someone else's land. According to
intellectual property law, the data transiting the Internet is owned
by its originator. That ownership does not change as the packets move
between my network and yours.

The point is, at every step with the Internet there is always a
specific owner whose property is either being used with his permission
or abused against his wishes. At no point is it a commons.

You must understand the Internet's nature before you can properly
consider my responsibility for the instructions passed from or through
my network which direct the action of computers in yours.

Regards,
Bill Herrin


-- 
William D. Herrin  her...@dirtside.com  b...@herrin.us
3005 Crane Dr. .. Web: 
Falls Church, VA 22042-3004



Re: Outgoing SMTP Servers

2011-10-27 Thread Pete Carah
On 10/27/2011 05:38 PM, valdis.kletni...@vt.edu wrote:
> On Thu, 27 Oct 2011 18:17:22 -, Brian Johnson said:
>> So... I'm in complete agreement with your statement, but The Wikipedia
reference is not pertinent.
>
> So I point out the tragedy of the commons, you agree with it, but the
Wikipedia
> reference that talks about the same exact thing isn't pertinent? How
does that
> follow? :)
Maybe he is concerned that the Wikipedia article gets into nit-picking
about the ownership of the commons that isn't relevant to our problem,
and also is rather long-winded.  Hardin got into some things at the end
of his paper that probably aren't either (but then, he was a population
biologist and not an economist).  BTW - that paper is a good read and
not too long.  The journal link (reference 1 in the wikipedia article)
actually works openly (AAAS only blocks full access for a while...)

For our purpose, the ownership of the commons in question truly isn't
relevant; the fundamental
statement of the tragedy for us is that a "useful" resource that is
incrementally free (or even cheap enough)
to a large number of participants will get exploited and probably overused.

I'm not aware of any solution to this problem with commons that doesn't
involve a central authority :-(
In feudal practice the landlord could do some enforcement; the spanish
alcaldes were another good example of a semi-central solution to the
commons problem (water rights in their origins, though their authority
grew over time).

Classic economics says that market pricing is the solution, but that
tends to result in another kind of tragedy.

-- Pete




Re: Outgoing SMTP Servers

2011-10-27 Thread Valdis . Kletnieks
On Thu, 27 Oct 2011 18:17:22 -, Brian Johnson said:
> So... I'm in complete agreement with your statement, but The Wikipedia 
> reference is not pertinent.

So I point out the tragedy of the commons, you agree with it, but the Wikipedia
reference that talks about the same exact thing isn't pertinent?  How does that
follow? :)



pgp9hn3urpTqJ.pgp
Description: PGP signature


Re: Outgoing SMTP Servers

2011-10-27 Thread William Herrin
On Thu, Oct 27, 2011 at 1:50 PM, Robert Bonomi  wrote:
> On Thu, 27 Oct 2011 13:53:34 -, Brian Johnson said:
>> As a small regional provider, implementing a "sane" port 25 filter has
>> saved us a lot of money and customer headaches over the years.
>>
>> It is interesting that some people who fully understand that the Internet is
>> composed of many networks run by people with different interests can say what
>> is best for the Internet as a whole. How my organization (or yours or anybody
>> else's) runs our network, is between us and our paying users.
>
> That claim is true *ONLY* to the extent that 'how your organization runs
> your network' does _not_ have an adverse effect on other peoples networks.

What I *prevent* from entering or leaving my network is *my business*,
between me and my customers.

What I allow to leave my network can become yours.

As with all rules, there's at least one exception: the monopoly or
duopoly vendor has an obligation to ensure that restrictions don't
abuse his position in the market. Nevertheless, "Mr. Small Business,
you shouldn't be blocking that packet, it's bad for the Internet," is
not for you or anyone else to say.

Regards,
Bill Herrin



-- 
William D. Herrin  her...@dirtside.com  b...@herrin.us
3005 Crane Dr. .. Web: 
Falls Church, VA 22042-3004



RE: Outgoing SMTP Servers

2011-10-27 Thread Brian Johnson
>-Original Message-
>From: Robert Bonomi [mailto:bon...@mail.r-bonomi.com]
>Sent: Thursday, October 27, 2011 12:50 PM
>To: nanog@nanog.org
>Subject: Re: Outgoing SMTP Servers
>
>
>On Thu, 27 Oct 2011 13:53:34 -, Brian Johnson said:
>
>> It is interesting that some people who fully understand that the Internet is
>> composed of many networks run by people with different interests can say
>what
>> is best for the Internet as a whole. How my organization (or yours or
>anybody
>> else's) runs our network, is between us and our paying users.
>
>That claim is true *ONLY* to the extent that 'how your organization runs
>your network' does _not_ have an adverse effect on other peoples networks.
>
>The fact of the matter is that you do not have a viable business without
>the collective 'tolerance'/'approval' of the rest of the world.
>

OK.

>You, and your organization, need them far more than they need you.
>

Argumentative and unnecessary.

>_How_ you pro-actively ensure spam does not exit from your network IS your
>business.
>
>That you *do* do so _is_ within the action purveiw of the 'rest of the world'.
>

Judge me as you will. My customers will determine if I change this policy. 
Their judgment is all that matters in this circumstance as the external 
Internet community has the access that the Internet community needs relative to 
this instance.

>"Doing so" requires that you _actively_ monitor the behavior of your
>customers
>and have 'ways and means' in place to (a) detect, and (b) _stop_ immediately
>upon detection, such abusive behavior by your customers.
>
>One of the 'easiest', and most _cost-effective_ ways of doing so *is* to
>force all outgoing mail from your customers through a 'choke point' for
>examination/filtering/blckcing.
>
>The simplest way of doing that, *without* running afoul of 'wiretapping'
>statutes. is to require, by policy and by blocking direct external access,
>that customer out-bound email traffic go through your servers, and doing
>the necessary 'inspection' there.
>
>

I think you support my position, but I could be convinced otherwise. :)

Be careful with you punctuation. I got lost a few times there :)

- Brian



RE: Outgoing SMTP Servers

2011-10-27 Thread Brian Johnson
>-Original Message-
>From: valdis.kletni...@vt.edu [mailto:valdis.kletni...@vt.edu]
>Sent: Thursday, October 27, 2011 10:24 AM
>To: Brian Johnson
>Cc: nanog@nanog.org
>Subject: Re: Outgoing SMTP Servers
>
>On Thu, 27 Oct 2011 13:53:34 -, Brian Johnson said:
>
>> It is interesting that some people who fully understand that the Internet is
>> composed of many networks run by people with different interests can say
>what
>> is best for the Internet as a whole. How my organization (or yours or
>anybody
>> else's) runs our network, is between us and our paying users.
>
>The fact that a behavior is "best" for your network does in no way, shape, or
>form, say anything about what's best for the Internet as a whole.  In fact,
>it's well-understood that there are entire classes of behaviors that are
>optimal for single actors, but fail when deployed widely.
>
>https://en.wikipedia.org/wiki/Tragedy_of_the_commons

So... I'm in complete agreement with your statement, but The Wikipedia 
reference is not pertinent (and a little sophomoric). :)





Re: Outgoing SMTP Servers

2011-10-27 Thread Robert Bonomi

On Thu, 27 Oct 2011 13:53:34 -, Brian Johnson said:

> It is interesting that some people who fully understand that the Internet is
> composed of many networks run by people with different interests can say what
> is best for the Internet as a whole. How my organization (or yours or anybody
> else's) runs our network, is between us and our paying users.

That claim is true *ONLY* to the extent that 'how your organization runs
your network' does _not_ have an adverse effect on other peoples networks.

The fact of the matter is that you do not have a viable business without 
the collective 'tolerance'/'approval' of the rest of the world.  

You, and your organization, need them far more than they need you.

_How_ you pro-actively ensure spam does not exit from your network IS your
business.

That you *do* do so _is_ within the action purveiw of the 'rest of the world'.

"Doing so" requires that you _actively_ monitor the behavior of your customers
and have 'ways and means' in place to (a) detect, and (b) _stop_ immediately
upon detection, such abusive behavior by your customers.

One of the 'easiest', and most _cost-effective_ ways of doing so *is* to 
force all outgoing mail from your customers through a 'choke point' for
examination/filtering/blckcing. 

The simplest way of doing that, *without* running afoul of 'wiretapping'
statutes. is to require, by policy and by blocking direct external access,
that customer out-bound email traffic go through your servers, and doing 
the necessary 'inspection' there.





Re: Outgoing SMTP Servers

2011-10-27 Thread Valdis . Kletnieks
On Thu, 27 Oct 2011 13:53:34 -, Brian Johnson said:

> It is interesting that some people who fully understand that the Internet is
> composed of many networks run by people with different interests can say what
> is best for the Internet as a whole. How my organization (or yours or anybody
> else's) runs our network, is between us and our paying users.

The fact that a behavior is "best" for your network does in no way, shape, or
form, say anything about what's best for the Internet as a whole.  In fact,
it's well-understood that there are entire classes of behaviors that are
optimal for single actors, but fail when deployed widely.

https://en.wikipedia.org/wiki/Tragedy_of_the_commons



pgpsP4OkXvIcU.pgp
Description: PGP signature


RE: Outgoing SMTP Servers

2011-10-27 Thread Brian Johnson
I find that large network providers have less issues with this issue.

As a small regional provider, implementing a "sane" port 25 filter has saved us 
a lot of money and customer headaches over the years. Our costs would be much 
higher if we could not save labor hours by implementing this. Possibly making 
service costs even more prohibitive. Pre implementation of these filters we had 
lower customer satisfaction, and were contemplating hiring more people to 
handle the labor load, due to UCE issues.

It is interesting that some people who fully understand that the Internet is 
composed of many networks run by people with different interests can say what 
is best for the Internet as a whole. How my organization (or yours or anybody 
else's) runs our network, is between us and our paying users.

But this thread has been interesting to follow. :)

 - Brian J.



>-Original Message-
>From: Owen DeLong [mailto:o...@delong.com]
>Sent: Wednesday, October 26, 2011 11:42 PM
>To: Scott Howard
>Cc: nanog@nanog.org
>Subject: Re: Outgoing SMTP Servers
>
>
>On Oct 26, 2011, at 8:07 PM, Scott Howard wrote:
>
>> On Tue, Oct 25, 2011 at 2:49 AM, Owen DeLong 
>wrote:
>> Interesting... Most people I know run the same policy on 25 and 587 these
>> days...
>>
>> to-local-domain, no auth needed.
>> relay, auth needed.
>>
>> auth required == TLS required.
>>
>> Anything else on either port seems not best practice to me.
>>
>> RFC 5068 covers the best practice, and it's not what you've got above.
>>
>> Allowing unauthenticated inbound mail on port 587 defeats the entire
>purpose of blocking port 25 - the front door is now closed to spammers, but
>you've left the back door open! (Security through obscurity saves you here in
>that spammers rarely use port 587 - yet).  There isn't a single situations 
>where
>you should be expecting an unauthenticated inbound message on the
>'Submission' port (is, 587)
>>
>I still believe that that RFC is not correct. That blocking port 25 has too 
>much
>collateral damage
>and is not a best practice.
>
>As such, you are correct, I am not following RFC 5068. A certain amount of
>spam does hit my
>system, but, the hosts that deliver it are identified and blocked reasonably
>quickly.
>
>> As much as some ISPs still resist blocking port 25 for residential 
>> customers, it
>does have a major impact on the volume of spam leaving your network.  I've
>worked with numerous ISPs as they have gone through the process of
>blocking port 25 outbound. In every case the number of end-user complaints
>has been low enough to be basically considered background noise, but the
>benefits have been significant - including one ISP who removed not only
>themselves but also their entire country from most of the 'Top 10 Spammers'
>list when they did it!
>>
>
>Blocking outbound port 25 would not reduce the already infinitesimal volume
>of spam leaving my network in the least. It would, however, block a lot of
>legitimate traffic.
>
>No thanks.
>
>Owen




Re: Outgoing SMTP Servers

2011-10-27 Thread Bjørn Mork
Owen DeLong  writes:
> On Oct 26, 2011, at 8:07 PM, Scott Howard wrote:
>
>> As much as some ISPs still resist blocking port 25 for residential
>> customers, it does have a major impact on the volume of spam leaving
>> your network.  I've worked with numerous ISPs as they have gone
>> through the process of blocking port 25 outbound. In every case the
>> number of end-user complaints has been low enough to be basically
>> considered background noise, but the benefits have been significant -
>> including one ISP who removed not only themselves but also their
>> entire country from most of the 'Top 10 Spammers' list when they did
>> it!
>> 
>
> Blocking outbound port 25 would not reduce the already infinitesimal
> volume of spam leaving my network in the least. It would, however,
> block a lot of legitimate traffic.
>
> No thanks.

I understand that.  But you may want to say "Yes, please" to having port
25 blocked by default while having the ability to turn that filter off.


As a residential user, the IP address you use to connect to MXs will
inevitably be one carved out of a pool allocated to residential users.
This is completely independent of whether you are using IPv4 or IPv6, or
having static or dynamic addresses.  You buy a residential product => 
you get a residential address. 

What that means to you, is that the filters running on all the MXs
around the world will classify *you* based on the observed behaviour of
all the residential customers of your ISP (among other factors of
course, but that's not relevant for this discussion).  If your ISP
offers an open port 25 to everyone policy, then you may experience that
your legitimate traffic drowns in a large volume of worm or virus
initiated traffic, making a number of MXs drop your traffic with the
rest of the bunch.

If, on the other hand, your ISP block port 25 by default and let you
disable the filter, then your traffic will probably account for a
significant part of the traffic the MXs of the world see from that
address pool.  This increases the probability that they classify the
pool as "friendly", and end up accepting your traffic.

Most MXs will probably have a sane enough policy to make them accept your
mail in either case.  But some won't. And as I'm sure you are aware of:
You can influence your local policy by choosing your ISP, but you can
rarely influence the policies of the MXs you want to talk to.

That's why you would want to say "yes, please" to the "filter by default
but offer a disable knob" service.



Bjørn



Re: Outgoing SMTP Servers

2011-10-27 Thread Bjørn Mork
Mark Andrews  writes:
> In message <4ea8a021.9000...@blakjak.net>, Mark Foster writes:
>
>> Why? It's a reasonable position; end users in the generic sense are
>> sending to whatever their client has set up for SMTP, fire-and-forget.  
>> Again, I feel like folks are taking their relatively complicated
>> use-cases and treating them as the norm.
>
> It's ths whole attitude that end users are incapable on doing thing
> correctly.   Most user are prefectly fine with having their mail
> go through a ISP's servers but there are exceptions and when people
> start say "only a ISP can do this" or "only business need this" by
> BS detector goes off because individuals do need to do the same
> sorts of things.

Yes.  Moving behind the BS, it's most likely a well calculated
difference between designing a product for 99% of the users or going for
the full 100%.  The problem is that some of the less technical ISP staff,
who often are involved in product definitons or financial and marketing
decisions, will think that 99% is "everyone" :-)

FWIW, we've been running a 25/tcp filter by default for a few years now,
offering a knob to turn it off from the start.  The knob is one of very
few settings the users are offered in their self-service web UI, along
with "change my password", "upgrade my account" and similar.  Disabling
the filter is of course free of charge. And when initially enabling the
filter, all users were informed about the possibility to turn it off.

Current status is that approx 1% of our users have disabled the filter
so far.  I assume most of them did so because they actually need access
to port 25/tcp, but some may have just turned it off to see what
happened and forgot about it. Filters will rarely be enabled again when
first disabled, as disabled filters naturally are unnoticable. This
makes the number of users disabling any given filter service aggregate
over time.

Anyway, that's the number we see. YMMV

Whether that 1% of users are important to you or not will probably
depend on a lot of factors.  But I believe it's safe to say that those
users can be classified as "power users", who will have a much higher
tendency to buy more expensive products and to discuss their their ISP
experiences with other power users.  This makes them a lot more valuable
than the number itself would indicate.



Bjørn



Re: Outgoing SMTP Servers

2011-10-26 Thread Owen DeLong

On Oct 26, 2011, at 8:07 PM, Scott Howard wrote:

> On Tue, Oct 25, 2011 at 2:49 AM, Owen DeLong  wrote:
> Interesting... Most people I know run the same policy on 25 and 587 these
> days...
> 
> to-local-domain, no auth needed.
> relay, auth needed.
> 
> auth required == TLS required.
> 
> Anything else on either port seems not best practice to me.
> 
> RFC 5068 covers the best practice, and it's not what you've got above.
> 
> Allowing unauthenticated inbound mail on port 587 defeats the entire purpose 
> of blocking port 25 - the front door is now closed to spammers, but you've 
> left the back door open! (Security through obscurity saves you here in that 
> spammers rarely use port 587 - yet).  There isn't a single situations where 
> you should be expecting an unauthenticated inbound message on the 
> 'Submission' port (is, 587)
> 
I still believe that that RFC is not correct. That blocking port 25 has too 
much collateral damage
and is not a best practice.

As such, you are correct, I am not following RFC 5068. A certain amount of spam 
does hit my
system, but, the hosts that deliver it are identified and blocked reasonably 
quickly.

> As much as some ISPs still resist blocking port 25 for residential customers, 
> it does have a major impact on the volume of spam leaving your network.  I've 
> worked with numerous ISPs as they have gone through the process of blocking 
> port 25 outbound. In every case the number of end-user complaints has been 
> low enough to be basically considered background noise, but the benefits have 
> been significant - including one ISP who removed not only themselves but also 
> their entire country from most of the 'Top 10 Spammers' list when they did it!
> 

Blocking outbound port 25 would not reduce the already infinitesimal volume of 
spam leaving my network in the least. It would, however, block a lot of 
legitimate traffic.

No thanks.

Owen



Re: Outgoing SMTP Servers

2011-10-26 Thread Scott Howard
On Tue, Oct 25, 2011 at 2:49 AM, Owen DeLong  wrote:

> Interesting... Most people I know run the same policy on 25 and 587 these
> days...
>
> to-local-domain, no auth needed.
> relay, auth needed.
>
> auth required == TLS required.
>
> Anything else on either port seems not best practice to me.
>

RFC 5068 covers the best practice, and it's not what you've got above.

Allowing unauthenticated inbound mail on port 587 defeats the entire purpose
of blocking port 25 - the front door is now closed to spammers, but you've
left the back door open! (Security through obscurity saves you here in that
spammers rarely use port 587 - yet).  There isn't a single situations where
you should be expecting an unauthenticated inbound message on the
'Submission' port (is, 587)

As much as some ISPs still resist blocking port 25 for residential
customers, it does have a major impact on the volume of spam leaving your
network.  I've worked with numerous ISPs as they have gone through the
process of blocking port 25 outbound. In every case the number of end-user
complaints has been low enough to be basically considered background noise,
but the benefits have been significant - including one ISP who removed not
only themselves but also their entire country from most of the 'Top 10
Spammers' list when they did it!

  Scott.


Re: Outgoing SMTP Servers

2011-10-26 Thread Jeff Kell
On 10/26/2011 10:57 PM, Scott Howard wrote:
> On Tue, Oct 25, 2011 at 2:51 AM, Aftab Siddiqui 
> wrote:
>
>> Blocking port/25 is a common practice (!= best practice) for home
>> users/consumers because it makes life a bit simpler in educating the end
>> user.

And it's not just 25.  I'm on Charter, and they're blocking 135-139,
445, and 1434 too.   Give Netalyzr a shot from your ISP.

Jeff



Re: Outgoing SMTP Servers

2011-10-26 Thread Scott Howard
On Tue, Oct 25, 2011 at 2:51 AM, Aftab Siddiqui wrote:

> Blocking port/25 is a common practice (!= best practice) for home
> users/consumers because it makes life a bit simpler in educating the end
> user.
>

MAAWG have considered this a best practice for residential/dynamic IPs since
2005 - http://www.uceprotect.net/downloads/MAAWGPort25English.pdf

The FTC and numerous other government agreed the same year -
http://www.ftc.gov/bcp/edu/microsites/spam/zombie/letter_english.pdf (The
URL in the pdf no longer works - it's not
http://www.ftc.gov/bcp/edu/microsites/spam/zombie/)

Anyone not yet past the denial stage on this one needs to get themselves a
copy of RFC 5068 and start reading.

  Scott.


Re: Outgoing SMTP Servers

2011-10-26 Thread Jay Ashworth
- Original Message -
> From: "Mark Andrews" 

> Now most people don't care about this but you shouldn't have to get
> a business grade service just to have secure email sessions and if
> you want to run a SMTP server to do that you are not changing the
> amount of traffic going over the connection so why the hell should
> a ISP care. IMAP, POP, SMTP all have about the same overhead for
> inbound email.

They shouldn't care.  Such users (probably 1% or less, though we tend, due to
nerdview, to forget that) are collateral damage to what they're *trying* to 
do, which is to block the 99% of the traffic with that profile, which is bot
spam.

This has nothing to do with bandwidth; that's a strawman.

Cheers,
-- jra
-- 
Jay R. Ashworth  Baylink   j...@baylink.com
Designer The Things I Think   RFC 2100
Ashworth & Associates http://baylink.pitas.com 2000 Land Rover DII
St Petersburg FL USA  http://photo.imageinc.us +1 727 647 1274



Re: Outgoing SMTP Servers

2011-10-26 Thread Mark Andrews

In message <4ea8a021.9000...@blakjak.net>, Mark Foster writes:
> On 27/10/11 11:11, Mark Andrews wrote:
> > In message , "Ricky Beam" writes:
> >> On Tue, 25 Oct 2011 15:52:46 -0400, Alex Harrowell 
>   
> >> wrote:>
> >>> Why do they do that?
> >> You'd have to ask them.  Or more accurately, you'd need to ask their  
> >> system integrator -- I've never seen an "in house" network run like that. 
>  
> >> (and for the record, they were charging for that shitty network access.)
> >>
> >> Bottom line: Blocking port 25 (smtp) is undesirable, but necessary for a  
> >> modern consumer internet. (Translation: It f'ing works.) This is the ISP  
> >> saying, "You aren't a mail *server*."  
> > MTA == Mail Transfer Agent.  You don't have to be a *server* to be
> > a MTA.  Blocking SMTP also prevents your customers running encrypted
> > mail sessions to prevent nosy ISP's and others looking at what they
> > are sending.  With DNSSEC now being deployed and DANE being
> > standardised, running a SMTP session with STARTTLS is being a
> > reality.
> 
> Perhaps i'm asking the obvious, but why is "Blocking SMTP" going to
> prevent customers running encrypted mail sessions?
> If SMTP = 25/TCP and encrypted mail sessions run on another port,
> they're not blocked?

It's encrypted email direct to MX.  With that I can know that the email
has been delivered to their mail exchangers.

> > Now most people don't care about this but you shouldn't have to get
> > a business grade service just to have secure email sessions and if
> > you want to run a SMTP server to do that you are not changing the
> > amount of traffic going over the connection so why the hell should
> > a ISP care.  IMAP, POP, SMTP all have about the same overhead for
> > inbound email.
> The majority of consumers will use the SMTP service their ISP provides
> and not look twice.
> Surely anyone wanting to use something different will either
> 
> a) run their own mail server, requiring a static IP address and simply
> requiring the ISP to flick a switch which says 'ok, you're not blocked
> for 25/TCP anymore'

And lots of ISP's don't offer those knobs in the misguided view that
individuals don't need them.

> b) use an alternative SMTP server on port != 25/TCP with their own
> authentication layer and responsibility thereof.

Which is just a non-starter.
 
> Sometimes I feel like contributors to NANOG see themselves as typical
> users.  IT Engineers are anything but typical when you compare to
> mom-and-pop-interwebs-user, and it's those very users who're likely to
> wind up with malware that'll be firing to random external SMTP servers
> via 25/TCP, delivering spam which is quite effectively blocked by a
> 25/TCP block.

As I said, most don't need it but for the few that do it should be
available and shouldn't require one to get a business service.  It's
like ISP's that won't deliver business grade services to homes.
Just because someone doesn't meet you pre-conceptions of their need
it doesn't mean that what they need is unreasonable.

> I've seen recently SMTP-AUTH sessions exploited (user/pass credentials
> borrowed) for spam purposes, but at least this is an order of magnitude
> more difficult for the spammer, and more easily tracked by the ISP than
> having to do IP/Time based records checks.
> >> MUA's (mail clients) should only be  
> >> connecting to specified MSA's or MTA's (mail *servers*).  They should  
> >> never be connecting to random MTA's (presumably for direct delivery, which
>   
> >> is the job of an MTA not MUA.) The only people who can effectively police 
>  
> >> this is the ISP.
> > Total utter BS.
> 
> Why? It's a reasonable position; end users in the generic sense are
> sending to whatever their client has set up for SMTP, fire-and-forget.  
> Again, I feel like folks are taking their relatively complicated
> use-cases and treating them as the norm.

It's ths whole attitude that end users are incapable on doing thing
correctly.   Most user are prefectly fine with having their mail
go through a ISP's servers but there are exceptions and when people
start say "only a ISP can do this" or "only business need this" by
BS detector goes off because individuals do need to do the same
sorts of things.

Mark.
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org



Re: Outgoing SMTP Servers

2011-10-26 Thread Mark Foster
On 27/10/11 11:11, Mark Andrews wrote:
> In message , "Ricky Beam" writes:
>> On Tue, 25 Oct 2011 15:52:46 -0400, Alex Harrowell   
>> wrote:>
>>> Why do they do that?
>> You'd have to ask them.  Or more accurately, you'd need to ask their  
>> system integrator -- I've never seen an "in house" network run like that.  
>> (and for the record, they were charging for that shitty network access.)
>>
>> Bottom line: Blocking port 25 (smtp) is undesirable, but necessary for a  
>> modern consumer internet. (Translation: It f'ing works.) This is the ISP  
>> saying, "You aren't a mail *server*."  
> MTA == Mail Transfer Agent.  You don't have to be a *server* to be
> a MTA.  Blocking SMTP also prevents your customers running encrypted
> mail sessions to prevent nosy ISP's and others looking at what they
> are sending.  With DNSSEC now being deployed and DANE being
> standardised, running a SMTP session with STARTTLS is being a
> reality.

Perhaps i'm asking the obvious, but why is "Blocking SMTP" going to
prevent customers running encrypted mail sessions?
If SMTP = 25/TCP and encrypted mail sessions run on another port,
they're not blocked?

> Now most people don't care about this but you shouldn't have to get
> a business grade service just to have secure email sessions and if
> you want to run a SMTP server to do that you are not changing the
> amount of traffic going over the connection so why the hell should
> a ISP care.  IMAP, POP, SMTP all have about the same overhead for
> inbound email.
The majority of consumers will use the SMTP service their ISP provides
and not look twice.
Surely anyone wanting to use something different will either

a) run their own mail server, requiring a static IP address and simply
requiring the ISP to flick a switch which says 'ok, you're not blocked
for 25/TCP anymore'
or
b) use an alternative SMTP server on port != 25/TCP with their own
authentication layer and responsibility thereof.

Sometimes I feel like contributors to NANOG see themselves as typical
users.  IT Engineers are anything but typical when you compare to
mom-and-pop-interwebs-user, and it's those very users who're likely to
wind up with malware that'll be firing to random external SMTP servers
via 25/TCP, delivering spam which is quite effectively blocked by a
25/TCP block.

I've seen recently SMTP-AUTH sessions exploited (user/pass credentials
borrowed) for spam purposes, but at least this is an order of magnitude
more difficult for the spammer, and more easily tracked by the ISP than
having to do IP/Time based records checks.
>> MUA's (mail clients) should only be  
>> connecting to specified MSA's or MTA's (mail *servers*).  They should  
>> never be connecting to random MTA's (presumably for direct delivery, which  
>> is the job of an MTA not MUA.) The only people who can effectively police  
>> this is the ISP.
> Total utter BS.

Why? It's a reasonable position; end users in the generic sense are
sending to whatever their client has set up for SMTP, fire-and-forget.  
Again, I feel like folks are taking their relatively complicated
use-cases and treating them as the norm.


Mark.



RE: Outgoing SMTP Servers

2011-10-26 Thread up
> On our retail footprint we block outbound traffic from customers with dynamic 
> IPs
> towards port 25, our support tells them to use their ISP's port 587 server
> That being said, since all of our home users have 50 mbit/sec or greater 
> upload
> speeds we are pretty paranoid about the amount of spam that could be 
> originated.
>
> We don't block anything on static assignments.   Honestly, even as a very 
> geeky
> user, I probably would not have noticed the block and I can confirm that it is
> massively important to lowering our spam footprint as a network.
>
> I asked our support people, and none of them had ever really had an issue with
> this policy in terms of keeping customers.   I agree with Ricky's current 
> comment
> on this thread, blocking is unfortunately necessary on the modern consumer
> portions of the internet.

Exactly.  Just like not having wide open SMTP relays became "unfortunately
necessary" over a dozen years ago.  It's just the way it is and there is a
solution for it.




Re: Outgoing SMTP Servers

2011-10-26 Thread Leigh Porter



On 26 Oct 2011, at 23:13, "Mark Andrews"  wrote:

> 
> In message , "Ricky Beam" writes:
>> On Tue, 25 Oct 2011 15:52:46 -0400, Alex Harrowell   
>> wrote:>
>>> Why do they do that?
>> 
>> You'd have to ask them.  Or more accurately, you'd need to ask their  
>> system integrator -- I've never seen an "in house" network run like that.  
>> (and for the record, they were charging for that shitty network access.)
>> 
>> Bottom line: Blocking port 25 (smtp) is undesirable, but necessary for a  
>> modern consumer internet. (Translation: It f'ing works.) This is the ISP  
>> saying, "You aren't a mail *server*."  
> 
> MTA == Mail Transfer Agent.  You don't have to be a *server* to be
> a MTA.  Blocking SMTP also prevents your customers running encrypted
> mail sessions to prevent nosy ISP's and others looking at what they
> are sending.  With DNSSEC now being deployed and DANE being
> standardised, running a SMTP session with STARTTLS is being a
> reality.
> 


This is what I used to do.

Any outgoing port 25 was sunk into a pool of SMTP proxies that I wrote. These 
proxies would look for signs of authentication and if they found them, the 
session would be proxied to the original destination SMTP server from the same 
IP address of the originating host.

Anything else was proxied to the pool of Ironports which would rate limit and 
otherwise SPAM examine the mail.

That way people using authenticated servers would be allowed through on the 
assumption that in all likelihood they were OK. Others who do not auth or are 
SPAM bots would be scrubbed and rate limited quite severely.

Our own customers were encouraged to use our outbound SMTP hosts which would 
either authenticate them if external or just allow them if internal, but with 
the SPAM scrubbing and less severe rate limiting enabled,

Customers who need a higher volume of outbound mail can call us and 
authenticate to the SMTP servers and we can set them a bespoke profile for rate 
limiting and message size etc etc.

That worked rather well because people's email got out and SPAM was largely 
stopped.

The Ironports were darn good boxes if a little pricey,

--
Leigh Porter


__
This email has been scanned by the MessageLabs Email Security System.
For more information please visit http://www.messagelabs.com/email 
__



Re: Outgoing SMTP Servers

2011-10-26 Thread Mark Andrews

In message , "Ricky Beam" writes:
> On Tue, 25 Oct 2011 15:52:46 -0400, Alex Harrowell   
> wrote:>
> > Why do they do that?
> 
> You'd have to ask them.  Or more accurately, you'd need to ask their  
> system integrator -- I've never seen an "in house" network run like that.  
> (and for the record, they were charging for that shitty network access.)
> 
> Bottom line: Blocking port 25 (smtp) is undesirable, but necessary for a  
> modern consumer internet. (Translation: It f'ing works.) This is the ISP  
> saying, "You aren't a mail *server*."  

MTA == Mail Transfer Agent.  You don't have to be a *server* to be
a MTA.  Blocking SMTP also prevents your customers running encrypted
mail sessions to prevent nosy ISP's and others looking at what they
are sending.  With DNSSEC now being deployed and DANE being
standardised, running a SMTP session with STARTTLS is being a
reality.

Now most people don't care about this but you shouldn't have to get
a business grade service just to have secure email sessions and if
you want to run a SMTP server to do that you are not changing the
amount of traffic going over the connection so why the hell should
a ISP care.  IMAP, POP, SMTP all have about the same overhead for
inbound email.

> MUA's (mail clients) should only be  
> connecting to specified MSA's or MTA's (mail *servers*).  They should  
> never be connecting to random MTA's (presumably for direct delivery, which  
> is the job of an MTA not MUA.) The only people who can effectively police  
> this is the ISP.

Total utter BS.

> Individual mail server admins and RBL maintainers can  
> only guess and be reactionary, which is often wrong, still lets spam  
> through, and becomes stale rather quickly.
> 
> --Ricky
> 
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org



RE: Outgoing SMTP Servers

2011-10-26 Thread John van Oppen
On our retail footprint we block outbound traffic from customers with dynamic 
IPs towards port 25, our support tells them to use their ISP's port 587 
server   That being said, since all of our home users have 50 mbit/sec or 
greater upload speeds we are pretty paranoid about the amount of spam that 
could be originated.

We don't block anything on static assignments.   Honestly, even as a very geeky 
user, I probably would not have noticed the block and I can confirm that it is 
massively important to lowering our spam footprint as a network.

I asked our support people, and none of them had ever really had an issue with 
this policy in terms of keeping customers.   I agree with Ricky's current 
comment on this thread, blocking is unfortunately necessary on the modern 
consumer portions of the internet. 


Thanks,
John van Oppen


-Original Message-
From: Owen DeLong [mailto:o...@delong.com] 
Sent: Monday, October 24, 2011 9:37 PM
To: Dennis Burgess
Cc: nanog@nanog.org
Subject: Re: Outgoing SMTP Servers


On Oct 24, 2011, at 9:29 PM, Dennis Burgess wrote:

> I am curious about what network operators are doing with outbound SMTP
> traffic.  In the past few weeks we have ran into over 10 providers,
> mostly local providers, which block outbound SMTP and require the users
> to go THOUGH their mail servers even though those servers are not
> responsible for the domains in question!  I know other mail servers are
> blocking non-reversible mail, however, is this common?  And more
> importantly, is this an acceptable practice?
> 

It's both unacceptable in my opinion and common. There are even those
misguided souls that will tell you it is best practice, though general 
agreement,
even among them seems to be that only 25/tcp should be blocked and that
465 and 587 should not be blocked.

> 
> 
> Most of our smaller ISPs that we support; we allow any outbound SMTP
> connection, however we do watch residential users for 5+ outbound SMTP
> connections at the same time.  But if the ISP has their own mail

> servers, and users wish to relay though them, we basically tell them to
> use their mail server that they contract with.  What is the best
> practice? 
> 

Best practice is to do what works and block as much SPAM as possible without
destroying the internet in the process. There are those who argue that blocking
25/tcp does not destroy the internet. By and large, they are the same ones who
believe NAT was good for us.

Owen





Re: Outgoing SMTP Servers

2011-10-26 Thread Ricky Beam
On Tue, 25 Oct 2011 15:52:46 -0400, Alex Harrowell   
wrote:>

Why do they do that?


You'd have to ask them.  Or more accurately, you'd need to ask their  
system integrator -- I've never seen an "in house" network run like that.  
(and for the record, they were charging for that shitty network access.)


Bottom line: Blocking port 25 (smtp) is undesirable, but necessary for a  
modern consumer internet. (Translation: It f'ing works.) This is the ISP  
saying, "You aren't a mail *server*."  MUA's (mail clients) should only be  
connecting to specified MSA's or MTA's (mail *servers*).  They should  
never be connecting to random MTA's (presumably for direct delivery, which  
is the job of an MTA not MUA.) The only people who can effectively police  
this is the ISP.  Individual mail server admins and RBL maintainers can  
only guess and be reactionary, which is often wrong, still lets spam  
through, and becomes stale rather quickly.


--Ricky



Re: Outgoing SMTP Servers

2011-10-26 Thread Henry Yen
On Wed, Oct 26, 2011 at 19:24:23PM -0600, Owen DeLong wrote:
> Firewalls are perfectly valid and I have no general objection to
> filtering packets based on the policy set by a site. What I object to is
> having someone I pay to move my packets tell me that they won't move
> some of those packets because they feel it is some form of best practice
> to eliminate my perfectly valid packets in order to prevent someone else
> from committing some form of abuse on the same protocol.
> 
> I object even more strenuously to someone who redirects my packets for
> their intended destination to some man in the middle attack destination
> of their choosing.

Would it be useful to slice this analysis into component parts, e.g.
"Residential" (dynamic), "small" (single/handful, e.g. small business,
colo, hosted web, VPS), and large (/24 and up), as what is defined as
"moving packets" may be viewed significantly differently?

For instance, what Residential customers are paying for seems to not
necessarily be (strictly speaking) "just moving all of your packets",
at least according to residential ToS' that I've read lately.

-- 
Henry Yen   Aegis Information Systems, Inc.
Senior Systems Programmer   Hicksville, New York



Re: Outgoing SMTP Servers

2011-10-26 Thread Ray Soucy
We provide service to about 1,000 public schools and libraries in the
state of Maine.

For those users, we block SMTP (port 25 only) traffic unless it goes
through our smarthost for incoming mail, and our mail-relay for
outgoing mail.

Otherwise we would be constantly ending up on blacklists, as many of
our users who attempt to run their own servers configure them to be
open relays, or don't secure host systems and have them turn into
botnets.

To make it a little more desirable we do provide a web UI to manage
mail domains, including letting them configure whether or not they
want to filter spam and some controls to how sensitive that is (kind
of like postini).

Recently, we've been rolling out Linux-based CPE instead of routers;
those provide them with a local firewall.  We've designed the firewall
to filter outgoing SMTP by default, but they can configure a list of
IP addresses to bypass that.  In this situation, they can run their
mail server directly on their network without making use of smarthost
or mail-relay, can manage exceptions, but still have a base-level of
protection against spam bots by default.

We have found that many of our users have come to prefer using our
relay servers as when something isn't working we can provide them with
logging information to help them track down the problem and they tend
to spend less time responding to spam incidents.

Whether or not this model could work commercially, I'm not sure... I
think we end up doing a lot more hand-holding than the typical ISP
given our audience.

As for our mail servers, both smarhost and mail-relay hosts we have
them point to actually point to several mail servers, and we do
perform base level greylisting and subscribe to a few blacklists
before mail is relayed or checked for spam and viruses.

On Tue, Oct 25, 2011 at 12:29 AM, Dennis Burgess
 wrote:
> I am curious about what network operators are doing with outbound SMTP
> traffic.  In the past few weeks we have ran into over 10 providers,
> mostly local providers, which block outbound SMTP and require the users
> to go THOUGH their mail servers even though those servers are not
> responsible for the domains in question!  I know other mail servers are
> blocking non-reversible mail, however, is this common?  And more
> importantly, is this an acceptable practice?
>
>
>
> Most of our smaller ISPs that we support; we allow any outbound SMTP
> connection, however we do watch residential users for 5+ outbound SMTP
> connections at the same time.  But if the ISP has their own mail
> servers, and users wish to relay though them, we basically tell them to
> use their mail server that they contract with.  What is the best
> practice?
>
>
>
>
>
> ---
> Dennis Burgess, Mikrotik Certified Trainer
> Link Technologies, Inc -- Mikrotik & WISP Support Services
> Office: 314-735-0270   Website:
> http://www.linktechs.net 
> LIVE On-Line Mikrotik Training 
> - Author of "Learn RouterOS" 
>
>
>
>



-- 
Ray Soucy

Epic Communications Specialist

Phone: +1 (207) 561-3526

Networkmaine, a Unit of the University of Maine System
http://www.networkmaine.net/



Re: Outgoing SMTP Servers

2011-10-26 Thread Leigh Porter
On 25 Oct 2011, at 09:34, "Tim"  wrote:

> This sadly is very common. It is getting more common by the day it seems but
> this practice has started almost a decade ago.
> 
> An easy work around is to use a custom port as they seem to just block port
> 25 as a bad port but leave just about everything else open including 2525
> which seems to be a common secondary smtp port for hosting companies.

I use port 80 which has not failed me so far ;-)

--
Leigh


__
This email has been scanned by the MessageLabs Email Security System.
For more information please visit http://www.messagelabs.com/email 
__



Re: Outgoing SMTP Servers

2011-10-26 Thread Owen DeLong
> 
> 
> 
> In a perfect world we would all have as many static globally routed IP
> addresses as we want with nothing filtered, in the real world a
> residential ISP who gives their customers globally routable IPv4
> addresses for each computer (ie. a CPE that supports multiple
> computers without NAT) with no filtering at all is probably going to
> have to hire more support staff to deal with it, even before people
> from this list start null routing their IP space for being a rogue ISP
> that clearly doesn't give a damn etc :)

Agreed that we should get to the point where everyone can have thousands of 
static globally routed subsets as soon as possible. The technology already 
exists and I use it wherever it is available. I have 65,536 static globally 
routed subsets available in my network, though I do not currently use that 
many. The reason we don't all have that yet is merely delay and inaction by 
those who have not yet implemented current IP technologies.
> 
> Perhaps our next try with IPv6 can be a perfect world where hosts are
> secure enough for open end to end connectivity and infected machines
> are rarely a problem? IPv6 enabled systems are more secure than a lot
> of the systems we have floating around on IPv4 networks, but I still
> think we're going to end up with port blocking becoming reasonably
> common on IPv6 as well once that starts getting widely deployed to
> residential users.
> 

Firewalls are perfectly valid and I have no general objection to filtering 
packets based on the policy set by a site. What I object to is having someone I 
pay to move my packets tell me that they won't move some of those packets 
because they feel it is some form of best practice to eliminate my perfectly 
valid packets in order to prevent someone else from committing some form of 
abuse on the same protocol.

I object even more strenuously to someone who redirects my packets for their 
intended destination to some man in the middle attack destination of their 
choosing.

Redirecting someones SMTP is a man I. The middle attack. It is every bit as 
evil as any other form of network abuse or hijacking.

Owen



Re: Outgoing SMTP Servers

2011-10-26 Thread Carlos Martinez-Cagnazzo
My point exactly, I am perfectly happy authenticating and relaying
through either my MX at the office or with Google's SMTP server. But I
just can't do that if SMTPoSSL ports are blocked by some lazy net
admin.

And I definitely hate it when I have to "pay" (in terms of delay and
overhead) the price of a VPN in order to just send a couple of emails.

cheers

Carlos

On Tue, Oct 25, 2011 at 1:57 PM, Dennis Burgess  wrote:
>
>>
>> I'm curious how a traveller is supposed to get SMTP relay service when, well,
>> travelling. I am not really sure if I want a VPN for sending a simple email.
>>
>> And I can understand (although I am not convinced that doing so is such a
>> great idea) blocking 25/tcp outgoing, as most botnets will try that method of
>> delivery. However, I do believe that outgoing 465 SHOULD always be
>> allowed.
>>
>> regards
>>
>> Carlos
>>
>
> [dmb] This is the exact question, why, do you NEED a SMTP Relay on ANY 
> network.  Your domain has a mail server out on the net that if you 
> authenticate to, I am sure will relay your mail, and the reverse DNS and SPF 
> records would match then as well.  Why does the local internet provide NEED 
> to relay though their server, regardless of the port.
>
>> On Tue, Oct 25, 2011 at 10:43 AM, Bjørn Mork  wrote:
>> > Owen DeLong  writes:
>> >
>> >> It's both unacceptable in my opinion and common. There are even those
>> >> misguided souls that will tell you it is best practice, though
>> >> general agreement, even among them seems to be that only 25/tcp
>> >> should be blocked and that
>> >> 465 and 587 should not be blocked.
>> >
>> > It is definitely considered best practice in some areas.  See e.g.
>> > http://translate.google.com/translate?hl=en&u=http://ikt-norge.no/wp-c
>> > ontent/uploads/2010/10/bransjenorm-SPAM.pdf
>> > (couldn't find an english original, but the google translation looks
>> > OK)
>> >
>> > The document is signed by all major ISPs in Norway as well as the
>> > Norwegian research and education network operator, so it must be
>> > considered a local "best practice" whether you like it or not.
>> >
>> > Note that only port 25/tcp is blocked and that some of the ISPs offer
>> > a per-subscriber optout.
>> >
>> > Eh, this was the Northern Aurope NOG, wasn't it?
>> >
>> >
>> >
>> >
>> > Bjørn
>> >
>> >
>>
>>
>>
>> --
>> --
>> =
>> Carlos M. Martinez-Cagnazzo
>> http://www.labs.lacnic.net
>> =
>
>
>



-- 
--
=
Carlos M. Martinez-Cagnazzo
http://www.labs.lacnic.net
=



Re: Outgoing SMTP Servers

2011-10-25 Thread Mike Jones
On 26 October 2011 05:44, Owen DeLong  wrote:
> Mike recommends a tactic that leads to idiot hotel admins doing bad things.
> You bet I'll criticize it for that.
>
> His mechanism breaks things anyway. I'll criticize it for that too.
>

Just to clarify, I was merely pointing out a possible argument behind
someone doing it that way. For a hotel wifi type network I would
consider it a valid option that is arguably (to some) better than
straight blocking for the average user, for other types of networks
with more long term user bases I would be very surprised if there was
any justification for redirecting as opposed to simply blocking. If
someone were asking for my advice on deploying a network like that I
would have to point out that the extra effort required to
deploy/support it is unlikely to be worth it. Blocking port 25 is
unlikely to cause much of a problem compared to a single incident with
that SMTP server that your hotel now needs to maintain.

In a perfect world we would all have as many static globally routed IP
addresses as we want with nothing filtered, in the real world a
residential ISP who gives their customers globally routable IPv4
addresses for each computer (ie. a CPE that supports multiple
computers without NAT) with no filtering at all is probably going to
have to hire more support staff to deal with it, even before people
from this list start null routing their IP space for being a rogue ISP
that clearly doesn't give a damn etc :)

Perhaps our next try with IPv6 can be a perfect world where hosts are
secure enough for open end to end connectivity and infected machines
are rarely a problem? IPv6 enabled systems are more secure than a lot
of the systems we have floating around on IPv4 networks, but I still
think we're going to end up with port blocking becoming reasonably
common on IPv6 as well once that starts getting widely deployed to
residential users.

- Mike



Re: Outgoing SMTP Servers

2011-10-25 Thread Robert Drake

On 10/25/2011 10:19 PM, Blake Hudson wrote:

I didn't see anyone address this from the service provider abuse
department perspective. I think larger ISP's got sick and tired of
dealing with abuse reports or having their IP space blocked because of
their own (infected) residential users sending out spam. The solution
for them was to block the spam. The cheapest/easiest way to do this was
to block TCP 25 between subs and the internet, thus starting a trend. If
587 becomes popular, spammers will move on and the same ISPs that
blocked 25 will follow suit.
Actually, it doesn't work that way because of what submission is 
designed to do.  I just posted another email about it so I won't repeat 
it, but basically you should think of blocking port 25 as a list of 
who's authorized to send emails, not as a port we just killed for fun 
and we're waiting for the spammers next move.




A better solution would have been to prevent infection or remove
infected machines from the network(strong abuse policies, monitoring,
give out free antivirus software, etc). Unfortunately, several major
players (ATT, for example) went down the road of limiting internet
access. Now that they've had a taste, some of them feel they can block
other ports or applications like p2p (Comcast), Netflix (usage based
billing on Bell, ATT, others).


As an ISP, I liked seeing abuse complaints drop to near zero when we did 
this.  We spent about a month fixing some people who don't use webmail 
(most regular customers don't use an MUA anymore) and had our share of 
third-party MTA's that refused to turn on submission (no idea why, these 
were usually business-class comp accounts so we moved them to a business 
pool and dropped their acls) but overall we probably had less than 100 
calls from doing this and it made our lives easier.


Now I know you said you wanted us to be preventative and to treat the 
problem, but that's just impractical.  We got 5000 abuse emails a month 
for (at the time) ~20k customers.  Were 1/4 of them spamming?  No, but 
the ones that were spamming generated automated reports from everyone.


None of them were ever legitimate spammers.  They were all users who 
clicked on a funny puppy picture their mom sent, or some other thing 
that set their computer on fire and had it spitting out gobs of porno 
links to everyone it could find.  So it wasn't a set of problem users, 
it was just a random sampling of everyone's not-so-PC-savvy relatives.


So, lets say we wrote software to collate those reports and got it down 
to 30 legitimate people (if we're lucky).  Do we block their IP's and 
wait for them to call in then send them to geek squad?  Do we try to fix 
their infected PC over the phone?   At this point, no matter what we do 
they're going to get sent to a tier 2 tech which means at least 2 phone 
calls and whatever revenue we might have gotten from them is gone for 
quite a while.  We can have one guy tied up all day every day trying to 
process abuse issues or we can just shut down port 25 and the problem 
magically disappears.


Is their laptop uninfected?  No, but they can no longer infect any other 
customer in our network or anyone elses network, thus reducing global 
infections.  We've made the world a better place and saved ourselves 
some money.   Unfortunately, the first coffee shop they go to that 
doesn't block port 25 is going to be a new spam source but we can't save 
them all.


It may be possible in the future we'll have a more convenient method to 
police PC's but the network access controls that exist right now aren't 
flexible enough to allow different networks to set different policies, 
so if it's a work laptop and they have a domain administrator then 
802.1x might not be possible, and mandating they have firewall or 
anti-virus turned on (or a specific version/that it's updated, etc) 
might not be possible.


Most customers rail against controls anyway.  You don't want port 25 
blocked so how would you feel if we mandated you install our ad-ware 
mcafee client and scanned your computer every 15 minutes?  And when you 
think about it, if the big boys gave up and blocked port 25 and stopped 
offering free anti-virus and a backrub when you call in, how can we 
afford to compete with that?




Unfortunately, I don't see the trend reversing. I'm afraid that Internet
freedoms are likely to continue to decline and an "Unlimited" Internet
experience won't exist at the residential level in 5+ years.


I hope that you're exaggerating for effect, but you might be right.  
Small providers have trouble competing right now because of all the 
advantages the carriers have in the market.  Some of the ways small 
providers can distinguish themselves is through support, or offering 
things a big player won't.  So in some cases it's better to find a 
regional ISP and go with them because they may work with you, and they 
may be a little more lenient with some things.


I don't think port 25 is worth making a stand on 

Re: Outgoing SMTP Servers

2011-10-25 Thread Robert Drake

On 10/25/2011 11:17 AM, Owen DeLong wrote:

But that applies to port 25 also, so, I'm not understanding the difference.


Other people running open port 587s tends to be quite self-correcting.


At this point, so do open port 25s.


The differences is in intentions from the user.   All SMTP servers are 
supposed to accept incoming email to their domain on port 25, if they 
get a connection from a random IP they can check spf, dkim and dns 
blacklists but that's all they can do to see the reputation of the 
sender.  Blocking port 25 is an ISP based list of who is allowed to send 
SMTP.


Port 587 is supposed to only be used for MUA-MTA communications.  If 
mx.hello.com gets a 587 connection from anyone and they say "mail from: 
" the server can drop that as wrong.


Yes it's nasty and dumb, but it works better than spf, DKIM and other 
technology right now.Maybe spf could be extended into reverse zones 
and who they're permitted to send mail for (too many ISP's don't let 
even business users update reverse records), maybe spf or a protocol 
like it will become required in the future so you know who can be 
trusted when they connect, or reputation or greylisting will take off, 
except for having to store reputation about all IP's and all /64s so the 
database isn't easily maintained.  I think spf with dkim (with caveats 
worked out) would be the best solution but anything that requires a flag 
day with SMTP basically isn't gonna happen.




Owen


Robert




Re: Outgoing SMTP Servers

2011-10-25 Thread Owen DeLong

On Oct 25, 2011, at 9:33 PM, William Herrin wrote:

> On Tue, Oct 25, 2011 at 8:15 PM, Owen DeLong  wrote:
>> On Oct 25, 2011, at 3:16 PM, William Herrin wrote:
>>> If you're doing the "right" thing, sending email via encrypted,
>>> authenticated mechanisms, then you're doing it TCP ports 587 or 443.
>>> Where Mike's mechanism obstructs you not at all.
>>> 
>> Depends. Some hotel admins aren't so bright. That's the problem. Not
>> everyone hears block outbound SMTP on port 25, they hear block outbound
>> SMTP and stop listening. Boom, 25, 465, 587 all get turned off.
> 
> Sure. But that's not Mike's mechanism. It's ignorant hotel guy's
> mechanism. Don't penalize Mike because some other fool does something
> similar but wrong.
> 
Mike recommends a tactic that leads to idiot hotel admins doing bad things.
You bet I'll criticize it for that.

His mechanism breaks things anyway. I'll criticize it for that too.

> 
>>> If you're still doing the wrong thing, trying to talk to remote SMTP
>>> servers on TCP port 25, why should his mechanisms not punish you?
>> 
>> It's not wrong to talk to them on port 25. It's wrong to allow 
>> unauthenticated
>> remote users to send on your own port 25 for relay purposes.
> 
> Sure it is. Same way it's wrong to have an open relay or an unsecured
> proxy. It isn't 1995 any more.
> 

As I said, we can agree to disagree about what is wrong. I know your position.
I still don't agree with it.

Owen




Re: Outgoing SMTP Servers

2011-10-25 Thread William Herrin
On Tue, Oct 25, 2011 at 8:15 PM, Owen DeLong  wrote:
> On Oct 25, 2011, at 3:16 PM, William Herrin wrote:
>> If you're doing the "right" thing, sending email via encrypted,
>> authenticated mechanisms, then you're doing it TCP ports 587 or 443.
>> Where Mike's mechanism obstructs you not at all.
>>
> Depends. Some hotel admins aren't so bright. That's the problem. Not
> everyone hears block outbound SMTP on port 25, they hear block outbound
> SMTP and stop listening. Boom, 25, 465, 587 all get turned off.

Sure. But that's not Mike's mechanism. It's ignorant hotel guy's
mechanism. Don't penalize Mike because some other fool does something
similar but wrong.


>> If you're still doing the wrong thing, trying to talk to remote SMTP
>> servers on TCP port 25, why should his mechanisms not punish you?
>
> It's not wrong to talk to them on port 25. It's wrong to allow unauthenticated
> remote users to send on your own port 25 for relay purposes.

Sure it is. Same way it's wrong to have an open relay or an unsecured
proxy. It isn't 1995 any more.

Regards,
Bill Herrin



-- 
William D. Herrin  her...@dirtside.com  b...@herrin.us
3005 Crane Dr. .. Web: 
Falls Church, VA 22042-3004



Re: Outgoing SMTP Servers

2011-10-25 Thread Graham Beneke
On 26/10/2011 04:35, Blake Hudson wrote:
> An infected machine can just as easily send out mail on port 587 as it
> can using port 25. It's not hard for bot net hearders to come up with a
> list of valid credentials stolen from email clients, via key loggers, or
> simply guessed through probability. I see it every day.

The difference is that it is the relay that accepts the spam on 587 that
ends up on the blacklists. A mail server with a sysadmin that might care
and probably sees business impact in not fixing the problem. As apposed
to an end user that doesn't give a hoot.

Compromised mail authentication details are quick and easy to take down.
A server mis-configured as an open relay on 587 is a one time fix.

End users infected with nasties are a support desk blackhole. Hours of
time explaining to moms and pops how to download anti-virus and install
it and configure it and run it...

-- 
Graham Beneke



Re: Outgoing SMTP Servers

2011-10-25 Thread Graham Beneke
On 25/10/2011 23:03, Mike Jones wrote:
> On 25 October 2011 20:52, Alex Harrowell  wrote:
>> Ricky Beam  wrote:
>>
>>> Works perfectly even in networks where a VPN doesn't and the idiot
>>> hotel
>>> intercepts port 25 (not blocks, redirects to *their* server.)
>>>
>>> --Ricky
>>
>> Why do they do that?
>>
> 
> If the hotel simply blocks port 25 then my email is broken, if they
> allow it then my email is broken (as my ISP doesn't let the hotel
> relay through their mail servers), however if the hotel redirects 25
> to their own open relays then in theory my email should work fine.

This only works if the MUA is configured to send to an un-AUTH'd relay
normally. It normally fails spectacularly when the MUA tries to present
AUTH that the relay doesn't understand or accept.

I know of at least one large consumer ISP that does this across their
network. Their argument was that it caused less of a support overhead
when they implemented since no one had to change any settings (in theory).

The reality is that the support overhead just transfers to the
hosting/mail provider. "I send mail via your server and you are
rejecting it." And then the hosting provider gets to explain how the IAP
is in fact mangling their customers mail.

Spam from mis-configured and compromised hosts is a big issue and on an
access network. Even worse with dynamically allocated IPs. Users dial up
and inherit blacklistings from previous customers and often entire
prefixes will be listed by the RBL if the snoeshow effect is big enough.

I dislike the idea of blocking port 25 (though it has been effective in
dealing with major outbreaks.) We ended up building an new product that
works as an appliance. All port 25 is piped through and the packets are
passed on un-touched. Spamminess is scored and with some clever
integration with RADIUS, the score is applied to a username. If the
threshold is exceeded then the user is dynamically blocked or directed
to a honeypot (depending on the requirements). And if the user redials
then the block follows them.

After deploying that our abuse desk went quiet ;-)

-- 
Graham Beneke



Re: Outgoing SMTP Servers

2011-10-25 Thread Blake Hudson



J wrote the following on 10/25/2011 9:25 PM:

Blake Hudson wrote:

If
587 becomes popular, spammers will move on and the same ISPs that
blocked 25 will follow suit.

I don't see this happening as easily.  Authenticated means an easier
shutdown of an account, rather than some form of port block/etc.
An infected machine can just as easily send out mail on port 587 as it 
can using port 25. It's not hard for bot net hearders to come up with a 
list of valid credentials stolen from email clients, via key loggers, or 
simply guessed through probability. I see it every day.


I will shutdown a compromised account on my end, but that doesn't stop 
ATT's infected subscriber from spamming 100 other servers using 100 
other stolen credentials. I may also send an abuse report to ATT if they 
have an infected machine trying to perform a dictionary attack or brute 
force logins against my port 587 SMTP server. ATT's going to deal with 
the abuse reports as cheaply as possible. If they receive enough, I have 
no doubt they'll repeat past mistakes.




Re: Outgoing SMTP Servers

2011-10-25 Thread J
Blake Hudson wrote:
> If
> 587 becomes popular, spammers will move on and the same ISPs that
> blocked 25 will follow suit.

I don't see this happening as easily.  Authenticated means an easier
shutdown of an account, rather than some form of port block/etc.

> A better solution would have been to prevent infection or remove
> infected machines from the network(strong abuse policies, monitoring,
> give out free antivirus software, etc).

We have 2/3 of that.  Antivirus helps some, but has some side-effects on the
helpdesk, if they're also the first response tier.

I find it strange mentioning 'monitoring' alongside 'freedoms', though.

> Unfortunately, I don't see the trend reversing. I'm afraid that Internet
> freedoms are likely to continue to decline and an "Unlimited" Internet
> experience won't exist at the residential level in 5+ years.

I'll agree with that.



Re: Outgoing SMTP Servers

2011-10-25 Thread Blake Hudson
I didn't see anyone address this from the service provider abuse 
department perspective. I think larger ISP's got sick and tired of 
dealing with abuse reports or having their IP space blocked because of 
their own (infected) residential users sending out spam. The solution 
for them was to block the spam. The cheapest/easiest way to do this was 
to block TCP 25 between subs and the internet, thus starting a trend. If 
587 becomes popular, spammers will move on and the same ISPs that 
blocked 25 will follow suit.


A better solution would have been to prevent infection or remove 
infected machines from the network(strong abuse policies, monitoring, 
give out free antivirus software, etc). Unfortunately, several major 
players (ATT, for example) went down the road of limiting internet 
access. Now that they've had a taste, some of them feel they can block 
other ports or applications like p2p (Comcast), Netflix (usage based 
billing on Bell, ATT, others).


Unfortunately, I don't see the trend reversing. I'm afraid that Internet 
freedoms are likely to continue to decline and an "Unlimited" Internet 
experience won't exist at the residential level in 5+ years.


--Blake



Re: Outgoing SMTP Servers

2011-10-25 Thread Jeroen van Aart

Owen DeLong wrote:

It's both unacceptable in my opinion and common. There are even those
misguided souls that will tell you it is best practice, though general 
agreement,
even among them seems to be that only 25/tcp should be blocked and that
465 and 587 should not be blocked.


From my consumer POV.

If you get a static IP with your provider, whether it is home internet 
or co-location, there should not be anything blocked. You're paying 
extra for the static IP in the case of home internet and the least you 
can expect is no blocking. Otherwise what's the point?


You can always block/cancel later in case of abuse obviously.

Of course this (and the below) does not apply in case of dynamically 
assigned IPs to a pool of home internet users.



Best practice is to do what works and block as much SPAM as possible without
destroying the internet in the process. There are those who argue that blocking
25/tcp does not destroy the internet. By and large, they are the same ones who
believe NAT was good for us.


There shouldn't be any spam filtering or blocking on a static IP at the 
ISP level. The ISP should limit itself to filtering at their own mail 
servers.


Greetings,
Jeroen

--
Earthquake Magnitude: 3.6
Date: Tuesday, October 25, 2011 18:20:24 UTC
Location: Arizona
Latitude: 34.8137; Longitude: -112.5391
Depth: 5.00 km



Re: Outgoing SMTP Servers

2011-10-25 Thread Owen DeLong

On Oct 25, 2011, at 3:16 PM, William Herrin wrote:

> On Tue, Oct 25, 2011 at 5:56 PM, Owen DeLong  wrote:
>> Put another way, your mechanism rewards those
>> doing the wrong thing while punishing those of us
>> sending our email via encrypted and authenticated
>> mechanisms.
> 
> Owen,
> 
> If you're doing the "right" thing, sending email via encrypted,
> authenticated mechanisms, then you're doing it TCP ports 587 or 443.
> Where Mike's mechanism obstructs you not at all.
> 
Depends. Some hotel admins aren't so bright. That's the problem. Not
everyone hears block outbound SMTP on port 25, they hear block outbound
SMTP and stop listening. Boom, 25, 465, 587 all get turned off.

Worse, if they redirect 25, then, it can still cause problems with many clients
because they will try 25 first assuming that if it is broken it will fail. 
There''s
nothing wrong with that approach IMHO. There's no reason one can't
send email over 25 just as well as 587 as long as they're authenticating
and doing it over an encrypted channel. My client generally tries in this
order: 25, 587, 465, 443, 80. If people merely break things by blocking
SMTP on one or more ports, then it works. If they do stupid pet tricks
like redirecting all connections to other addresses to their own server,
then it breaks horribly.

> If you're still doing the wrong thing, trying to talk to remote SMTP
> servers on TCP port 25, why should his mechanisms not punish you?
> 

It's not wrong to talk to them on port 25. It's wrong to allow unauthenticated
remote users to send on your own port 25 for relay purposes.

This is the problem... I don't buy your idea of what constitutes doing
the wrong thing and neither do the developers of many email clients.

Owen




Re: Outgoing SMTP Servers

2011-10-25 Thread Douglas Otis

On 10/25/11 12:31 PM, Ricky Beam wrote:

 On Tue, 25 Oct 2011 12:55:58 -0400, Owen DeLong 
 wrote:
> Wouldn't the right place for that form of rejection to occur be at
> the mail server in question?



 In a perfect world, yes. When you find a perfect world, send us an
 invite.



> I reject lots of residential connections...

 The real issue here is *KNOWING* who is residential or not. Only
 the ISP knows for sure; and they rarely tell others. The various
 blocklists are merely guessing. Using a rDNS name is an even worse
 guess.


Agreed.   Don't expect a comprehensive list based upon rDNS containing 
specific host names with IPv6.  That would represent a never ending 
process to collect.



> However, senders who authenticate legitimately or legitimate
> sources of email (and yes, some spam sources too) connect just
> fine.



 Authenticated sources can be traced and shutoff. If a random
 cablemodem user has some bot spewing spam, the only way to cut off
 the spam is to either (gee) block outbound port 25, or turn their
 connection off entirely. As a responsible admin, I'll take the
 least disruptive path. (I'll even preemptively do so.)


Blocking ports is not free, but don't expect all DSL providers to 
unblock port 25 unless it is for a business account.  Price 
differentials help pay for port blocking.


In a perfect world, all SMTP transactions would cryptographically 
authenticate managing domains for the MTA.  With less effort and 
resources (than that needed to check block lists) IPv6 could continue to 
work through LSNs aimed at helping those refusing to offer IPv6 
connectivity.  Blocking at the prefix requires block list resources 65k 
times greater than what is currently needed for IPv4.  IPv6 
announcements seem likely to expand another 6 fold fairly soon as well.


In comparison, cryptographic authentication would be more practical, but 
a hybrid Kerberos scheme supported by various third-party service 
providers could reduce the overhead.  Is it time for AuthenticatedMTP?


-Doug





Re: Outgoing SMTP Servers

2011-10-25 Thread William Herrin
On Tue, Oct 25, 2011 at 5:56 PM, Owen DeLong  wrote:
> Put another way, your mechanism rewards those
>doing the wrong thing while punishing those of us
>sending our email via encrypted and authenticated
>mechanisms.

Owen,

If you're doing the "right" thing, sending email via encrypted,
authenticated mechanisms, then you're doing it TCP ports 587 or 443.
Where Mike's mechanism obstructs you not at all.

If you're still doing the wrong thing, trying to talk to remote SMTP
servers on TCP port 25, why should his mechanisms not punish you?

Regards,
Bill Herrin


-- 
William D. Herrin  her...@dirtside.com  b...@herrin.us
3005 Crane Dr. .. Web: 
Falls Church, VA 22042-3004



Re: Outgoing SMTP Servers

2011-10-25 Thread Owen DeLong
No no no no no. 

The problem with your theory below is that:

1. It is by far best for users to authenticate to send mail. 

2. Your "solution" works only for unencrypted unauthenticated users that ignore 
the certificate presented by the mail server. 

Put another way, your mechanism rewards those doing the wrong thing while 
punishing those of us sending our email via encrypted and authenticated 
mechanisms. 

That's a very bad thing. 

Owen


Sent from my iPhone

On Oct 25, 2011, at 15:03, Mike Jones  wrote:

> On 25 October 2011 20:52, Alex Harrowell  wrote:
>> Ricky Beam  wrote:
>> 
>>> Works perfectly even in networks where a VPN doesn't and the idiot
>>> hotel
>>> intercepts port 25 (not blocks, redirects to *their* server.)
>>> 
>>> --Ricky
>> 
>> Why do they do that?
>> 
> 
> My home ISP run an open relay on port 25 with IP-based authentication,
> so I might configure my laptops email client to send email via
> smtp.myisp.com port 25 (many/most? residential ISPs have
> unauthenticated relays, even ISPs that tell you to use authentication
> often have another server next to it that doesn't need authentication
> for customer IP space)
> 
> If the hotel simply blocks port 25 then my email is broken, if they
> allow it then my email is broken (as my ISP doesn't let the hotel
> relay through their mail servers), however if the hotel redirects 25
> to their own open relays then in theory my email should work fine.
> 
> They could always tell people "there is a relay at 10.0.0.25 so you
> can change your settings to use that", however by redirecting all port
> 25 traffic there they are effectively forcibly auto-configuring anyone
> who was already configured to send via an unauthenticated server on
> port 25. They are probably acting under the assumption that the only
> people using 25 are using it for unauthenticated access, I believe
> most servers that do use authentication tell users to use alternate
> ports so this is probably a reasonable assumption.
> 
> Compared to straight blocking of port 25 it's probably better as long
> as the relay it is redirecting you to works properly so you don't have
> to try and diagnose issues - However considering the quality of the
> average hotel network I suspect most of them that are trying to do
> this probably have it set to redirect to a dead server anyway.
> 
> - Mike



Re: Outgoing SMTP Servers

2011-10-25 Thread Mike Jones
On 25 October 2011 20:52, Alex Harrowell  wrote:
> Ricky Beam  wrote:
>
>>Works perfectly even in networks where a VPN doesn't and the idiot
>>hotel
>>intercepts port 25 (not blocks, redirects to *their* server.)
>>
>>--Ricky
>
> Why do they do that?
>

My home ISP run an open relay on port 25 with IP-based authentication,
so I might configure my laptops email client to send email via
smtp.myisp.com port 25 (many/most? residential ISPs have
unauthenticated relays, even ISPs that tell you to use authentication
often have another server next to it that doesn't need authentication
for customer IP space)

If the hotel simply blocks port 25 then my email is broken, if they
allow it then my email is broken (as my ISP doesn't let the hotel
relay through their mail servers), however if the hotel redirects 25
to their own open relays then in theory my email should work fine.

They could always tell people "there is a relay at 10.0.0.25 so you
can change your settings to use that", however by redirecting all port
25 traffic there they are effectively forcibly auto-configuring anyone
who was already configured to send via an unauthenticated server on
port 25. They are probably acting under the assumption that the only
people using 25 are using it for unauthenticated access, I believe
most servers that do use authentication tell users to use alternate
ports so this is probably a reasonable assumption.

Compared to straight blocking of port 25 it's probably better as long
as the relay it is redirecting you to works properly so you don't have
to try and diagnose issues - However considering the quality of the
average hotel network I suspect most of them that are trying to do
this probably have it set to redirect to a dead server anyway.

- Mike



Re: Outgoing SMTP Servers

2011-10-25 Thread Robert Bonomi
> From nanog-bounces+bonomi=mail.r-bonomi@nanog.org  Tue Oct 25 14:53:32 
> 2011
> Subject: Re: Outgoing SMTP Servers
> From: Alex Harrowell 
> Date: Tue, 25 Oct 2011 20:52:46 +0100
> To: Ricky Beam , Jeroen Massar 
> Cc: nanog@nanog.org
>
> Ricky Beam  wrote:
>
> >Works perfectly even in networks where a VPN doesn't and the idiot
> >hotel  
> >intercepts port 25 (not blocks, redirects to *their* server.)
> >
> >--Ricky
>
> Why do they do that?

Because some "quarter-asswit"[1] sold them that it was a good idea -- maybe
on the basis tht it was: "easy" to to rate-limit -- supposedly an anti-spam 
measure; "easy" to 'forward' all the patron traffic to a relay server of the
hotel's choice, so that, -if- it is spam, the outside world sees it coming 
from an already segregated address-space; "easy" to implement a holding 
queue, so that if they _do_ detect spam, they can drop _all_ the spam 
messages, even those sent before the spam threshold was detected.; etc., 
etc., ad nauseum.




[1] "half-assed half-wit", reduced to a single term. 



Re: Outgoing SMTP Servers

2011-10-25 Thread Alex Harrowell
Ricky Beam  wrote:

>Works perfectly even in networks where a VPN doesn't and the idiot
>hotel  
>intercepts port 25 (not blocks, redirects to *their* server.)
>
>--Ricky

Why do they do that?

-- 
Sent from my Android phone with K-9 Mail. Please excuse my brevity.



Re: Outgoing SMTP Servers

2011-10-25 Thread Ricky Beam

On Tue, 25 Oct 2011 07:15:00 -0400, Jeroen Massar  wrote:

On that iToy of yours it is just a flick of a switch, presto.


Where "flick of a switch" is actually several steps...
  Settings -> Network -> VPN... there's your switch.
  Wait for it to connect
  Go back to mail, refresh...

And one's VPN profile has to be setup in advance.

Plus, it doesn't always work.  I gather you've never been in a network  
where an IPSec VPN wouldn't connect.  I've seen it too many times. (I've  
even seen ISPs where it didn't work.  Apparently GRE isn't IP to them.)   
An SSL VPN will often get around that, but it's additional  
hardware/software/setup/licenses/etc. (For a Cisco ASA, it's an additional  
word in your vpn setup, and a license... base "demo" is only 2  
connections.)


It's *MUCH* easier to setup the mail server on ports 465 and 587, require  
auth and tls.  Done right, it's 100% transparent to the traveling user.   
Works perfectly even in networks where a VPN doesn't and the idiot hotel  
intercepts port 25 (not blocks, redirects to *their* server.)


--Ricky



Re: Outgoing SMTP Servers

2011-10-25 Thread Ricky Beam

On Tue, 25 Oct 2011 12:55:58 -0400, Owen DeLong  wrote:

Wouldn't the right place for that form of rejection to occur be at the
mail server in question?


In a perfect world, yes.  When you find a perfect world, send us an invite.


I reject lots of residential connections...


The real issue here is *KNOWING* who is residential or not.  Only the ISP  
knows for sure; and they rarely tell others.  The various blocklists are  
merely guessing.  Using a rDNS name is an even worse guess.



However, senders who authenticate legitimately or legitimate sources
of email (and yes, some spam sources too) connect just fine.


Authenticated sources can be traced and shutoff.  If a random cablemodem  
user has some bot spewing spam, the only way to cut off the spam is to  
either (gee) block outbound port 25, or turn their connection off  
entirely.  As a responsible admin, I'll take the least disruptive path.  
(I'll even preemptively do so.)


--Ricky



Re: Outgoing SMTP Servers

2011-10-25 Thread Brian Dickson
Owen wrote:

>On Oct 25, 2011, at 3:29 AM,  wrote:
>
>> On Tue, 25 Oct 2011 02:35:31 PDT, Owen DeLong said:
>>
>>> If they are using someone else's mail server for outbound, how, exactly do 
>>> you control
>>> whether or not they use AUTH in the process?
>>
>> 1) You don't even really *care* if they do or not, because...
>>
>> 2) if some other site is running with an un-AUTHed open port 587, the 
>> miscreants will
>> find it and abuse it just like any other open mail relay. The community will
>> deal with it quick enough so you don't have to. And at that point, it's the
>> open mail relay's IP that ends up on the block lists, not your mail relay's 
>> IP.
>>
>But that applies to port 25 also, so, I'm not understanding the difference.
>
>> Other people running open port 587s tends to be quite self-correcting.
>>
>
>At this point, so do open port 25s.
>
>Owen

I'll try to explain with text stick-diagrams...

The players are:
G - good user
B - botnet host
I - ISP
O - open relay
S - mail-submission relay
V - victim SMTP/mailbox host

It's all about how port-25 traffic containing SPAM gets to machine
"V". (Or not, which is the preferred situation.)

Possible routes include:
B.25 -> (I allows 25) -> O -> V (classic open relay) [SPAM]
B.25 -> (I allows 25) -> V (new mode, and what William Herrin is
talking about) [SPAM]
B.587 -> (I !allow 25) -> V (but that makes no sense - how does B
authenticate to the victim? She doesn't!!) [BLOCKED]
B.587 -> (I !allow 25) -> S (ditto - not an open unauthenticated
relay, only allows authenticated relaying!!!) [BLOCKED]

Meanwhile, we have:
G.587 -> (I !allow 25) -> S.g.587/.25 (mail submission gateway for G)
-> V.25 [NOT-SPAM && NOT-BLOCKED]

S.g is either G's enterprise mail server, or G's home mail server, or
G's ISP themselves, or some other S to which G can authenticate.
S.g receives on 587, and sends on 25, and is a generally reputable
port-25 host (whatever that means).

So, basically, not blocking 587 and blocking 25 removes all the
avenues for direct botnet spam.
Authenticating botnet sources become trackable on auth-hosts, and easy
to shut down.

Is there some path not listed above that could allow a spammer (botnet
host) behind the ISP to send email, without having a relay host to
which it can authenticate, that I'm not seeing?

Brian



RE: Outgoing SMTP Servers

2011-10-25 Thread Matt McBride
We use Mailchannels to route all outbound mail through it, which does a decent 
job of keeping garbage off the Internet and SBLs/RBLs clean. It is dependent on 
PBR so there is overhead to manage it but the product runs on our own hardware.

-Matt

-Original Message-
From: Owen DeLong [mailto:o...@delong.com] 
Sent: Tuesday, October 25, 2011 10:56 AM
To: William Herrin
Cc: nanog@nanog.org
Subject: Re: Outgoing SMTP Servers


On Oct 25, 2011, at 8:46 AM, William Herrin wrote:

> On Tue, Oct 25, 2011 at 5:49 AM, Owen DeLong  wrote:
>> On Oct 24, 2011, at 11:13 PM, William Herrin wrote:
>>> Blocking outbound TCP SYN packets on port 25 from non-servers is
>>> considered a BEST PRACTICE to avoid being the source of snowshoe and
>>> botnet spam. Blocking it from legitimate mail servers... does not make
>>> sense.
>>> 
>>> The SMTP submission port (TCP 587) is authenticated and should
>>> generally not be blocked.
>> 
>> Interesting... Most people I know run the same policy on 25 and 587 these
>> days...
> 
> Owen,
> 
> Perhaps you misunderstand the issue. The issue is not relaying mail
> through someone else's mail server, it's delivering mail to a mailbox
> served by that mail server. 99.99 etc. percent of the time when that's
> done directly from a IP address that's supposed to be user PC it's
> some form of spam. Hence the best practice within the email community
> is to ask the networking community to block those packets outright.
> And its why residential ISPs who fail to tend to find their way into
> Spamcop, Spamhaus and others. Facilitating that sort of network
> filtering is precisely why authenticated SMTP relaying was assigned
> port 587 instead of leaving it on port 25.
> 

Wouldn't the right place for that form of rejection to occur be at the
mail server in question?

Precluding users doing legitimate things just because there are users
who do illegitimate things is damaging to the internet and I will continue
to route around it.

I reject lots of residential connections to my port 25 services every day.
However, senders who authenticate legitimately or legitimate sources
of email (and yes, some spam sources too) connect just fine.

> 
> On Tue, Oct 25, 2011 at 11:28 AM, Carlos Martinez-Cagnazzo
>  wrote:
>> I'm curious how a traveller is supposed to get SMTP relay service
>> when, well, travelling. I am not really sure if I want a VPN for
>> sending a simple email.
> 
> That's what the SMTP submission port (TCP 587) is intended for and
> it's why outbound 587 should not be blocked. In fact, blocking 587 can
> cause problems with folks who use the Sender Policy Framework to
> restrict the servers allowed to pass mail from a particular domain
> outward.
> 

So the spammers move to 587 and problem solved.

Owen





Re: Outgoing SMTP Servers

2011-10-25 Thread Owen DeLong

On Oct 25, 2011, at 8:46 AM, William Herrin wrote:

> On Tue, Oct 25, 2011 at 5:49 AM, Owen DeLong  wrote:
>> On Oct 24, 2011, at 11:13 PM, William Herrin wrote:
>>> Blocking outbound TCP SYN packets on port 25 from non-servers is
>>> considered a BEST PRACTICE to avoid being the source of snowshoe and
>>> botnet spam. Blocking it from legitimate mail servers... does not make
>>> sense.
>>> 
>>> The SMTP submission port (TCP 587) is authenticated and should
>>> generally not be blocked.
>> 
>> Interesting... Most people I know run the same policy on 25 and 587 these
>> days...
> 
> Owen,
> 
> Perhaps you misunderstand the issue. The issue is not relaying mail
> through someone else's mail server, it's delivering mail to a mailbox
> served by that mail server. 99.99 etc. percent of the time when that's
> done directly from a IP address that's supposed to be user PC it's
> some form of spam. Hence the best practice within the email community
> is to ask the networking community to block those packets outright.
> And its why residential ISPs who fail to tend to find their way into
> Spamcop, Spamhaus and others. Facilitating that sort of network
> filtering is precisely why authenticated SMTP relaying was assigned
> port 587 instead of leaving it on port 25.
> 

Wouldn't the right place for that form of rejection to occur be at the
mail server in question?

Precluding users doing legitimate things just because there are users
who do illegitimate things is damaging to the internet and I will continue
to route around it.

I reject lots of residential connections to my port 25 services every day.
However, senders who authenticate legitimately or legitimate sources
of email (and yes, some spam sources too) connect just fine.

> 
> On Tue, Oct 25, 2011 at 11:28 AM, Carlos Martinez-Cagnazzo
>  wrote:
>> I'm curious how a traveller is supposed to get SMTP relay service
>> when, well, travelling. I am not really sure if I want a VPN for
>> sending a simple email.
> 
> That's what the SMTP submission port (TCP 587) is intended for and
> it's why outbound 587 should not be blocked. In fact, blocking 587 can
> cause problems with folks who use the Sender Policy Framework to
> restrict the servers allowed to pass mail from a particular domain
> outward.
> 

So the spammers move to 587 and problem solved.

Owen




Re: Outgoing SMTP Servers

2011-10-25 Thread Randy Bush
> I'm curious how a traveller is supposed to get SMTP relay service
> when, well, travelling. I am not really sure if I want a VPN for
> sending a simple email.

vpn

i use openvpn

when roaming, i am often on poorly protected wireless.  i openvpn to
home

randy



Re: Outgoing SMTP Servers

2011-10-25 Thread David E. Smith
On Tue, Oct 25, 2011 at 10:57, Dennis Burgess wrote:

>
> [dmb] This is the exact question, why, do you NEED a SMTP Relay on ANY
> network.  Your domain has a mail server out on the net that if you
> authenticate to, I am sure will relay your mail, and the reverse DNS and SPF
> records would match then as well.  Why does the local internet provide NEED
> to relay though their server, regardless of the port.
>
>
Not every domain actually has a mail server that allows remote
authentication/relay. People hosting small vanity domains with cheap hosting
providers might not. Maybe people using small ISPs with less-than-top-notch
staff. Heck, maybe there's just a short-term issue with the mail server, and
you still want/need to send something out right now, so you use your ISP's
mail system.

David Smith
MVN.net


RE: Outgoing SMTP Servers

2011-10-25 Thread Dennis Burgess

> 
> I'm curious how a traveller is supposed to get SMTP relay service when, well,
> travelling. I am not really sure if I want a VPN for sending a simple email.
> 
> And I can understand (although I am not convinced that doing so is such a
> great idea) blocking 25/tcp outgoing, as most botnets will try that method of
> delivery. However, I do believe that outgoing 465 SHOULD always be
> allowed.
> 
> regards
> 
> Carlos
> 

[dmb] This is the exact question, why, do you NEED a SMTP Relay on ANY network. 
 Your domain has a mail server out on the net that if you authenticate to, I am 
sure will relay your mail, and the reverse DNS and SPF records would match then 
as well.  Why does the local internet provide NEED to relay though their 
server, regardless of the port.  

> On Tue, Oct 25, 2011 at 10:43 AM, Bjørn Mork  wrote:
> > Owen DeLong  writes:
> >
> >> It's both unacceptable in my opinion and common. There are even those
> >> misguided souls that will tell you it is best practice, though
> >> general agreement, even among them seems to be that only 25/tcp
> >> should be blocked and that
> >> 465 and 587 should not be blocked.
> >
> > It is definitely considered best practice in some areas.  See e.g.
> > http://translate.google.com/translate?hl=en&u=http://ikt-norge.no/wp-c
> > ontent/uploads/2010/10/bransjenorm-SPAM.pdf
> > (couldn't find an english original, but the google translation looks
> > OK)
> >
> > The document is signed by all major ISPs in Norway as well as the
> > Norwegian research and education network operator, so it must be
> > considered a local "best practice" whether you like it or not.
> >
> > Note that only port 25/tcp is blocked and that some of the ISPs offer
> > a per-subscriber optout.
> >
> > Eh, this was the Northern Aurope NOG, wasn't it?
> >
> >
> >
> >
> > Bjørn
> >
> >
> 
> 
> 
> --
> --
> =
> Carlos M. Martinez-Cagnazzo
> http://www.labs.lacnic.net
> =




Re: Outgoing SMTP Servers

2011-10-25 Thread William Herrin
On Tue, Oct 25, 2011 at 5:49 AM, Owen DeLong  wrote:
> On Oct 24, 2011, at 11:13 PM, William Herrin wrote:
>> Blocking outbound TCP SYN packets on port 25 from non-servers is
>> considered a BEST PRACTICE to avoid being the source of snowshoe and
>> botnet spam. Blocking it from legitimate mail servers... does not make
>> sense.
>>
>> The SMTP submission port (TCP 587) is authenticated and should
>> generally not be blocked.
>
> Interesting... Most people I know run the same policy on 25 and 587 these
> days...

Owen,

Perhaps you misunderstand the issue. The issue is not relaying mail
through someone else's mail server, it's delivering mail to a mailbox
served by that mail server. 99.99 etc. percent of the time when that's
done directly from a IP address that's supposed to be user PC it's
some form of spam. Hence the best practice within the email community
is to ask the networking community to block those packets outright.
And its why residential ISPs who fail to tend to find their way into
Spamcop, Spamhaus and others. Facilitating that sort of network
filtering is precisely why authenticated SMTP relaying was assigned
port 587 instead of leaving it on port 25.


On Tue, Oct 25, 2011 at 11:28 AM, Carlos Martinez-Cagnazzo
 wrote:
> I'm curious how a traveller is supposed to get SMTP relay service
> when, well, travelling. I am not really sure if I want a VPN for
> sending a simple email.

That's what the SMTP submission port (TCP 587) is intended for and
it's why outbound 587 should not be blocked. In fact, blocking 587 can
cause problems with folks who use the Sender Policy Framework to
restrict the servers allowed to pass mail from a particular domain
outward.

Regards,
Bill Herrin




-- 
William D. Herrin  her...@dirtside.com  b...@herrin.us
3005 Crane Dr. .. Web: 
Falls Church, VA 22042-3004



Re: Outgoing SMTP Servers

2011-10-25 Thread Owen DeLong

On Oct 25, 2011, at 4:15 AM, Jeroen Massar wrote:

> On 2011-10-25 12:20 , Owen DeLong wrote:
>> 
>> On Oct 25, 2011, at 3:04 AM, Jeroen Massar wrote:
>> 
>>> On 2011-10-25 11:49 , Owen DeLong wrote:
>>> [..]
 With this combination, I have not encountered a hotel, airport lounge, or
 other poorly run environment from which I cannot send mail through my
 home server from my laptop/ipad/iphone/etc.
>>> 
>>> Ever heard of this magical thing called a VPN? :)
>> 
>> Sure, but, why deal with the overhead? Who wants to have to login to a
>> VPN every time just to quickly retrieve or send some email?
> 
> On that iToy of yours it is just a flick of a switch, presto.
> 
On anything, a VPN is a diversion of your traffic through a tunnel with 
additional
overhead for encryption and encapsulation headers.

>>> Indeed, that bypasses all those crappy local networks; and yes don't
>>> worry your iToy also has more than ample VPN abilities.
>>> 
>> 
>> Some do, some don't, and not all networks are any friendlier to VPNs
>> than they are to port 25.
> 
> And the final solution then tends to be setting up a VPN on port 443...
> Which only wastes one IP address, not several for different services.
> 
Meh, there are plenty of IP addresses. The shortage is limited to this legacy
v4 stuff. When the hotel networks and such catch up to the modern internet,
I can stop running these extra addresses on IPv4 and it won't matter.

>>> Set up once and never have to bother about special configurations or
>>> getting around stupid filters.
>>> 
>> 
>> Except where you have to or where there are so many layers of NAT that
>> even VPNs don't work, or...
> 
> Unless this 'NAT' is actually a firewall doing DPI on the packets, I
> can't see any reason why a VPN which just uses TCP over port 443 can't
> work in that situation.
> 

You would think, but, I have seen them break. OTOH, most of my VPNs
are IPSEC, not SSL, so that's another issue. There would be significant
additional overhead in setting up an SSL VPN. Admittedly, it's one-time
overhead, but, again, I don't see a reason to bother.

Owen




Re: Outgoing SMTP Servers

2011-10-25 Thread Carlos Martinez-Cagnazzo
I'm curious how a traveller is supposed to get SMTP relay service
when, well, travelling. I am not really sure if I want a VPN for
sending a simple email.

And I can understand (although I am not convinced that doing so is
such a great idea) blocking 25/tcp outgoing, as most botnets will try
that method of delivery. However, I do believe that outgoing 465
SHOULD always be allowed.

regards

Carlos

On Tue, Oct 25, 2011 at 10:43 AM, Bjørn Mork  wrote:
> Owen DeLong  writes:
>
>> It's both unacceptable in my opinion and common. There are even those
>> misguided souls that will tell you it is best practice, though general 
>> agreement,
>> even among them seems to be that only 25/tcp should be blocked and that
>> 465 and 587 should not be blocked.
>
> It is definitely considered best practice in some areas.  See e.g.
> http://translate.google.com/translate?hl=en&u=http://ikt-norge.no/wp-content/uploads/2010/10/bransjenorm-SPAM.pdf
> (couldn't find an english original, but the google translation looks OK)
>
> The document is signed by all major ISPs in Norway as well as the
> Norwegian research and education network operator, so it must be
> considered a local "best practice" whether you like it or not.
>
> Note that only port 25/tcp is blocked and that some of the ISPs offer a
> per-subscriber optout.
>
> Eh, this was the Northern Aurope NOG, wasn't it?
>
>
>
>
> Bjørn
>
>



-- 
--
=
Carlos M. Martinez-Cagnazzo
http://www.labs.lacnic.net
=



Re: Outgoing SMTP Servers

2011-10-25 Thread Owen DeLong

On Oct 25, 2011, at 3:29 AM,  wrote:

> On Tue, 25 Oct 2011 02:35:31 PDT, Owen DeLong said:
> 
>> If they are using someone else's mail server for outbound, how, exactly do 
>> you control
>> whether or not they use AUTH in the process?
> 
> 1) You don't even really *care* if they do or not, because...
> 
> 2) if some other site is running with an un-AUTHed open port 587, the 
> miscreants will
> find it and abuse it just like any other open mail relay. The community will
> deal with it quick enough so you don't have to. And at that point, it's the
> open mail relay's IP that ends up on the block lists, not your mail relay's 
> IP.
> 
But that applies to port 25 also, so, I'm not understanding the difference.

> Other people running open port 587s tends to be quite self-correcting.
> 

At this point, so do open port 25s.

Owen




Re: Outgoing SMTP Servers

2011-10-25 Thread Bjørn Mork
Owen DeLong  writes:

> It's both unacceptable in my opinion and common. There are even those
> misguided souls that will tell you it is best practice, though general 
> agreement,
> even among them seems to be that only 25/tcp should be blocked and that
> 465 and 587 should not be blocked.

It is definitely considered best practice in some areas.  See e.g.
http://translate.google.com/translate?hl=en&u=http://ikt-norge.no/wp-content/uploads/2010/10/bransjenorm-SPAM.pdf
(couldn't find an english original, but the google translation looks OK)

The document is signed by all major ISPs in Norway as well as the
Norwegian research and education network operator, so it must be
considered a local "best practice" whether you like it or not.

Note that only port 25/tcp is blocked and that some of the ISPs offer a
per-subscriber optout.

Eh, this was the Northern Aurope NOG, wasn't it?




Bjørn



Re: Outgoing SMTP Servers

2011-10-25 Thread Jeroen Massar
On 2011-10-25 12:20 , Owen DeLong wrote:
> 
> On Oct 25, 2011, at 3:04 AM, Jeroen Massar wrote:
> 
>> On 2011-10-25 11:49 , Owen DeLong wrote:
>> [..]
>>> With this combination, I have not encountered a hotel, airport lounge, or
>>> other poorly run environment from which I cannot send mail through my
>>> home server from my laptop/ipad/iphone/etc.
>>
>> Ever heard of this magical thing called a VPN? :)
> 
> Sure, but, why deal with the overhead? Who wants to have to login to a
> VPN every time just to quickly retrieve or send some email?

On that iToy of yours it is just a flick of a switch, presto.

>> Indeed, that bypasses all those crappy local networks; and yes don't
>> worry your iToy also has more than ample VPN abilities.
>>
> 
> Some do, some don't, and not all networks are any friendlier to VPNs
> than they are to port 25.

And the final solution then tends to be setting up a VPN on port 443...
Which only wastes one IP address, not several for different services.

>> Set up once and never have to bother about special configurations or
>> getting around stupid filters.
>>
> 
> Except where you have to or where there are so many layers of NAT that
> even VPNs don't work, or...

Unless this 'NAT' is actually a firewall doing DPI on the packets, I
can't see any reason why a VPN which just uses TCP over port 443 can't
work in that situation.

Greets,
 Jeroen



Re: Outgoing SMTP Servers

2011-10-25 Thread Valdis . Kletnieks
On Tue, 25 Oct 2011 02:35:31 PDT, Owen DeLong said:

> If they are using someone else's mail server for outbound, how, exactly do 
> you control
> whether or not they use AUTH in the process?

1) You don't even really *care* if they do or not, because...

2) if some other site is running with an un-AUTHed open port 587, the 
miscreants will
find it and abuse it just like any other open mail relay. The community will
deal with it quick enough so you don't have to. And at that point, it's the
open mail relay's IP that ends up on the block lists, not your mail relay's IP.

Other people running open port 587s tends to be quite self-correcting.



pgpyXFMmAdPlt.pgp
Description: PGP signature


Re: Outgoing SMTP Servers

2011-10-25 Thread Owen DeLong

On Oct 25, 2011, at 3:04 AM, Jeroen Massar wrote:

> On 2011-10-25 11:49 , Owen DeLong wrote:
> [..]
>> With this combination, I have not encountered a hotel, airport lounge, or
>> other poorly run environment from which I cannot send mail through my
>> home server from my laptop/ipad/iphone/etc.
> 
> Ever heard of this magical thing called a VPN? :)

Sure, but, why deal with the overhead? Who wants to have to login to a
VPN every time just to quickly retrieve or send some email?

> 
> Indeed, that bypasses all those crappy local networks; and yes don't
> worry your iToy also has more than ample VPN abilities.
> 

Some do, some don't, and not all networks are any friendlier to VPNs
than they are to port 25.

> Set up once and never have to bother about special configurations or
> getting around stupid filters.
> 

Except where you have to or where there are so many layers of NAT that
even VPNs don't work, or...

I set up the 5 ports once and don't need any special configurations to
get around stupid filters, stuff just works now.

Owen




Re: Outgoing SMTP Servers

2011-10-25 Thread Jeroen Massar
On 2011-10-25 11:49 , Owen DeLong wrote:
[..]
> With this combination, I have not encountered a hotel, airport lounge, or
> other poorly run environment from which I cannot send mail through my
> home server from my laptop/ipad/iphone/etc.

Ever heard of this magical thing called a VPN? :)

Indeed, that bypasses all those crappy local networks; and yes don't
worry your iToy also has more than ample VPN abilities.

Set up once and never have to bother about special configurations or
getting around stupid filters.

Greets,
 Jeroen



Re: Outgoing SMTP Servers

2011-10-25 Thread Owen DeLong

On Oct 24, 2011, at 11:13 PM, William Herrin wrote:

> On Tue, Oct 25, 2011 at 12:29 AM, Dennis Burgess
>  wrote:
>> I am curious about what network operators are doing with outbound SMTP
>> traffic.  In the past few weeks we have ran into over 10 providers,
>> mostly local providers, which block outbound SMTP and require the users
>> to go THOUGH their mail servers even though those servers are not
>> responsible for the domains in question!  I know other mail servers are
>> blocking non-reversible mail, however, is this common?  And more
>> importantly, is this an acceptable practice?
> 
> Hi Dennis,
> 
> Blocking outbound TCP SYN packets on port 25 from non-servers is
> considered a BEST PRACTICE to avoid being the source of snowshoe and
> botnet spam. Blocking it from legitimate mail servers... does not make
> sense.
> 
> The SMTP submission port (TCP 587) is authenticated and should
> generally not be blocked.
> 

Interesting... Most people I know run the same policy on 25 and 587 these
days...

to-local-domain, no auth needed.
relay, auth needed.

auth required == TLS required.

Anything else on either port seems not best practice to me.

Due to the absurd things I've seen done in the world, I actually
run that policy on 5 ports:

25, 587 as you would expect.
465 SSL rather than STARTTLS, but, otherwise identical
80 because it works when nothing else does.
443 because sometimes Deep Packet Inspection is a PITA.

Of course, using 80 and 443 requires the use of additional IP address
resources for those servers rather than being able to also run a web
server on the same address, but, this is the consequence of replacing
an internet with 64K ports with filters that force the entire internet to
operate all services on TCP/80.

With this combination, I have not encountered a hotel, airport lounge, or
other poorly run environment from which I cannot send mail through my
home server from my laptop/ipad/iphone/etc.

Owen




Re: Outgoing SMTP Servers

2011-10-25 Thread Aftab Siddiqui
Blocking port/25 is a common practice (!= best practice) for home
users/consumers because it makes life a bit simpler in educating the end
user.

ripe-409 gives some what glimpse of best-practice, not sure how many
implements it that way.

Regards,

Aftab A. Siddiqui


On Tue, Oct 25, 2011 at 2:35 PM, Owen DeLong  wrote:

>
> On Oct 24, 2011, at 10:27 PM, Mikael Abrahamsson wrote:
>
> > On Mon, 24 Oct 2011, Dennis Burgess wrote:
> >
> >> I am curious about what network operators are doing with outbound SMTP
> >> traffic.
> >
> > Block all TCP/25 and require users to use submit with authentication on
> TCP/587.
> >
>
> If they are using someone else's mail server for outbound, how, exactly do
> you control
> whether or not they use AUTH in the process?
>
> Further, if you make them use AUTH somehow, but, you don't force TLS, then,
> you are
> doing more harm than good IMHO.
>
> Owen
>
>
>


Re: Outgoing SMTP Servers

2011-10-25 Thread Owen DeLong

On Oct 24, 2011, at 10:27 PM, Mikael Abrahamsson wrote:

> On Mon, 24 Oct 2011, Dennis Burgess wrote:
> 
>> I am curious about what network operators are doing with outbound SMTP
>> traffic.
> 
> Block all TCP/25 and require users to use submit with authentication on 
> TCP/587.
> 

If they are using someone else's mail server for outbound, how, exactly do you 
control
whether or not they use AUTH in the process?

Further, if you make them use AUTH somehow, but, you don't force TLS, then, you 
are
doing more harm than good IMHO.

Owen




Re: Outgoing SMTP Servers

2011-10-25 Thread Dave CROCKER


On 10/25/2011 8:13 AM, William Herrin wrote:

Blocking outbound TCP SYN packets on port 25 from non-servers is
considered a BEST PRACTICE

...

The SMTP submission port (TCP 587) is authenticated and should
generally not be blocked.



   Email Submission Operations: Access and Accountability Requirements

     IETF BCP

It does not explicitly support blocking outbound port 25, since that's 
controversial, but it /does/ require permitting outbound port 587.


d/



Regards,
Bill Herrin




--

  Dave Crocker
  Brandenburg InternetWorking
  bbiw.net



RE: Outgoing SMTP Servers

2011-10-25 Thread Tim
This sadly is very common. It is getting more common by the day it seems but
this practice has started almost a decade ago.

An easy work around is to use a custom port as they seem to just block port
25 as a bad port but leave just about everything else open including 2525
which seems to be a common secondary smtp port for hosting companies.




Re: Outgoing SMTP Servers

2011-10-24 Thread William Herrin
On Tue, Oct 25, 2011 at 12:29 AM, Dennis Burgess
 wrote:
> I am curious about what network operators are doing with outbound SMTP
> traffic.  In the past few weeks we have ran into over 10 providers,
> mostly local providers, which block outbound SMTP and require the users
> to go THOUGH their mail servers even though those servers are not
> responsible for the domains in question!  I know other mail servers are
> blocking non-reversible mail, however, is this common?  And more
> importantly, is this an acceptable practice?

Hi Dennis,

Blocking outbound TCP SYN packets on port 25 from non-servers is
considered a BEST PRACTICE to avoid being the source of snowshoe and
botnet spam. Blocking it from legitimate mail servers... does not make
sense.

The SMTP submission port (TCP 587) is authenticated and should
generally not be blocked.

Regards,
Bill Herrin


-- 
William D. Herrin  her...@dirtside.com  b...@herrin.us
3005 Crane Dr. .. Web: 
Falls Church, VA 22042-3004



  1   2   >