[unisog] Any Canadian Universities on here ?

Daniel Feenberg feenberg at nber.org
Thu May 5 22:00:55 GMT 2005



On Thu, 5 May 2005, PaulFM wrote:

> So you would have caught it just as fast had you logged all outgoing port 25 
> connections rather than block them.
> 
> You realize, with the new standard (port 587) it will only be a matter of 
> time before there are a bunch of port 587 mail relays and everyone will be 
> talking about blocking them.

I have never encountered an MSA at port 587 that did not require
login/password - do people do that? What would the purpose be? To run an
open relay? At one time there was considerable demand for that, but I
don't see much any more.

Port 25 is special because by tradition and convention it accepted
connections from (nearly) anyone. An ISP would block outbound connections
to port 25 of external hosts to prevent outbound spam. Port 587 (by
tradition and convention) requires a login, so spam sent out to port 587
any MTA is rejected by that MTA, hence the ISP will feel no pressure to
block 587 even if all ISPs block outbound connections to port 25 for all
their dynamically assigned hosts.

The situation is not comparable to the consequences of blocking a port
used by p2p software, where the software can easily coordinate with itself
to use a different port. In this case the MTA operator would have to
cooperate - and he has no incentive to do so.

If the MTA requires a login/password at port 587, it is of course likely
that spammers will eventually train their software to steal the
identifiers, however this is not a fatal objection to SMTP-AUTH on port
587. The operator of the MTA can still block that user when he finds it
spewing spam. I have seen it argued that an ISP would hesitate to do so,
since it might lose a customer. While this is possible, it doesn't have
much relevance to a University, and I expect most ISP customers will
simply get a Yahoo/Hotmail/Gmail account and shrug off the restriction.

> 
> It is much more important to block incoming ports to all but authorized 
> machines (cut off the control connection to the spam-bots).
> 

The spambots don't "phone home" for instructions? We block all incoming
connections to all our PCs - does that protect them from becoming
spam-bots? I'd like to feel that was true, but I understood it was weak
protection. Maybe I missunderstand.


> Sylvain Robitaille wrote:
> 
> > On Wed, 4 May 2005, Pete Hickey wrote:
> > 
> > 
> >>it is EXTREMELY useful to be able to come into our mail machines for
> >>debugging.
> > 
> > 
> > Oh, I agree, but does that cost outweight the benefit?
> > 
> > 
> >>And the spammers will then have their zombie machines go through the
> >>ISP's SMTP relay.
> > 
> > 
> > Of course, but then the ISP is in a much better position to a) detect
> > the problem as it is happening, and b) deal with it much sooner.
> > 
> > We had an example of that exact scenario happen here a few months back:
> > a system that had been compromised was being used for sending spam,
> > but we block outbound port 25, so outbound mail goes only through our
> > sanctioned mail servers.
> > 
> > I noticed the load average on one of the mail servers was staying
> > unusually high for a rather long time, and when I looked more closely,
> > sure enough it was in the process of trying to deliver a bunch of queued
> > up spam.  I probably would not have "detected" this happening with the
> > old direct spamming method until the complaints started coming in, but
> > in this case I was able to put a stop to it after "only" a few thousand
> > messages had gotten out.
> > 
> > It's obviously not perfect, but it does help.  It also permits us to
> > apply virus-detection to outbound as well as inbound mail, helping also
> > at that level.
> > 
> > 
> >>Starting off, we would tell them.  Configure your mailer to use
> >>xxx as your mailbox server, and yyy as your mail relay/SMTP-out.
> >>Use that whether you are at home or in the office.
> > 
> > 
> > I would argue that was a mistake.  Our mail servers were refusing
> > third-party relaying many years ago.  We've been telling our users
> > pretty much all along, though certainly since the larger ISPs have been
> > in place that they should configure mail software on computers connected
> > to our network to use our mail servers for relaying, and on ISP-connected
> > computers to use the ISP's mail servers.
> > 
> > If the user is having trouble with the ISP's mail server, they're
> > directed to the ISP's support service.
> > 
> > 
> >>Oh yes.. There was one ISP who would not accept mail for relay
> >>unless it had THEIR domain in the From:
> > 
> > 
> > I don't feel we should make concessions for ISPs who misunderstand the
> > protocols.  If we had a user with that problem, I would recommend to the
> > user (cc: postmaster at the ISP) to find a better ISP (and I have done
> > that in some cases, though not yet for this reason).
> > 
> 
> 




More information about the unisog mailing list