Avleen Vig wrote:
>
> On Sun, Mar 21, 2004 at 10:43:13PM -0600, Edgar Lovecraft wrote:
> > This is not true, the majority, or all Sat services require you to
> > 'dial-up' for outbound content, they must still dial up somewhere, and
> > at that somewhere there is a router, any ISP is going to have a router
> > that is capable of blocking TCP port traffic, the same is true with
> > Cable, DSL, wireless, and standard dial-up connection. There will
> > always be a 'router' at the 'connection point' to the rest of the
> > world (internal to an ISP's network could be different, but that all
> > depends on the ISP and how they have setup the internal network), as
> > an example, my home ISP is Cox Cable, I do not have 'a direct
> > connection to the Internet' as some believe, my Cable modem gets an IP
> > address from a Cox DHCP server, and Cox has routers that take my
> > traffic to the 'world at large'
> > example partial trace to www.exim.org from my workstation:
..[snip]... (that gets messy after too many replys :)
> > As you can see, there are at least six devices under the direct control
> > of Cox Communications that could be set to block any port they desire.
> > The same is true for any connection including 'piggy back' ISP's such
> > as the AOL braodband type of connections.
>
> Wrong. While you some of what you say is correct, when you get to the
> "piggy-back" ISP stage everything falls apart. AOL, MSN, Earthlink, and
> all the other cable piggy-backers pass through the *same* gear at the
> Cable ISP. There is no way for the cable co's routers to know (AFAIK)
> the Edgar is a Cox, Earthlink, MSN or AOL customer. When this is the
> case, how does the router tell which SMTP server to allow access to? Of
> course the best answer is shut off SMTP and force everyone to use SMTP
> AUTH only. :-)
>
Absolutely, use SMTP AUTH, but perhaps I used bad wording or did not
clarify properly in my first posting...
The piggy-backers are on MY ISP's connection, and MY ISP can and should be
shutting down port 25. The piggy-backers are really no different (please
I do understand all of the technical diffs here) than me 'piggy-backing'
onto my companies VPN. So this does not fall apart, as for example, AOL,
MSN, Earthlink, are not 'my real ISP' anymore (they do not control the
hardware anymore than my company does when I connect to a VPN), and as such
would (in the examples we are discussing) offer SMTP on say port 587 (which
was designed for this in the first place), so all of the 'install' docs and
such would say 'you must use port xxx for outbound SMTP'. So how does this
fall apart?
>
> > AOL does use many other less publicized anti-spam measures that are
> > good, just for example, not gauranteeing that they will accept email
> > or connections from MTA servers that have NO rDNS. These are the
> > types of things that they really should be marketing, not SPF as AOL
> > may/may not care if they break someone's personal web page. But when
> > they do, what is thier 'fix' for thier customer?
> > That is another reason I prefer an approach to what I stated, at least
> > the ISP's could say hey, you just cannot send on tcp port 25, but...
>
> There are a lot of anti-spam measure that are having to take effect
> because we didn't design SMTP right from the start (and that's no-one's
> fault, we could never envision this), and we didn't fix it when we had
> the chance.
>
Here I would disagree some, but not completely.
Just as an exercise, take your MTA and set it so that everything has to
conform to the RFC standards (connection information, message header/body
formats, etc), and see how much email good and bad, does not get delivered.
As it right now, you cannot do this and have 'happy' users.
You can read one of my rants on this here:
http://www.exim.org/pipermail/exim-users/Week-of-Mon-20031201/063313.html
I still agree with most everything I put in that post, with a few
exceptions/additions.
One-> I think (even though it does go against the RFC's) all MTA's should
enforce the 'rDNS == DNS A == HELO name'
Two-> If a server rejects MAIL and RCPT commands from <> and <postmast@...>
they should be blacklisted as they are causing a severe disservice to their
users (do not deliver such email to them if you want, but the take the
commands and at least pretend to care :).
Three-> ISP's should block tcp port 25 outbound from DUL type connections.
Four-> Those 'in the know' need to help educate those that are not on how a
proper MTA needs to be configured for RFC compliance. (this is something I
already do every chance I get)
>
> As a result we're now putting fix on top of fix to work around the
> multitude of problems (SPF, SpamAssassin, hash-cashing, etc etc). I
> believe some of these should be *protocol* issues, not application
> level.
>
My point is, before we start 'putting fix on top of fix' lets first
enforce the STMP Standards as stated in RFC 821, 822, 2821, 2822 and a few
others that are at least 'in common use' (yes there are more than just
those four, but they cover pretty much all we need for this discussion).
SPF amongst some other 'proposels' do not really help much when the basics
are not being enforced and used first. Once the basics are enforced it
makes all the rest much much easier to deal with.
>
> But the fact is, we're here. We need to make the best of a bad
> situation, and what EVER we choose, there will be people who are upset
> with it. We need to agree that like there isn't one solution to the spam
> problem, there isn't any solution that will make everyone happy. So this
> will get decided one of two ways:
> 1) A few people get around a table, hash a solution out, which
> everyone agrees to follow (no matter what it is)
> 2) or the majority will pick one solution, and if everyone wants their
> mail to carry on working as it used to, they'll fall in line and a few
> months later forget what the fuss was about.
--
I do agree that something must be done, and that not everyone will be
happy. Whether anyone likes it or not it will be choice two that
determines what if anything gets done, but keep three things in mind,
one, SPF does break email forwarding in a lot or most cases unless a
messages headers and such are 'hacked up' before the message is sent (this
is a bad thing as the more an admin has to do this the more likely there
will be mistakes), two, 'the majority' can be as small as a few very large
ISP's, and three, 'the majority' does not always make the 'best' or
'easiest' implementation choices :)
Just a some thoughts...
And by the way, I am not an all out anti-SPF person, I just think that it
needs a little bit more thinking through before it becomes 'the standard',
that the current RFC's plus 'rDNS == DNS A == HELO name' should be 'forced'
on MTA admins before we worry about SPF, and that it would be very helpfull
if outbound port 25 became a 'closed' port for most systems.
I will give the SPF implementation the credit that it does not 'delay'
email delivery by forcing a resend or a webpage 'yes I did send it'
confirmation, and the SPF website has some good information on what a
proper MTA should really look like from a 'tcp connection/DNS' stand
point. ;)
--EAL--
