-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
First -
Forgive me for the return-receipt request. My-Bad!
And, as for my thoughts on accountability, I fully expect to be putting
out flames for days. But, before you hammer me too hard . . . please
consider this. Irrespective of the technical matters associated with
making the end ISP's accountable, is there some logical reason to create
a system to fix something that is only broken because of lack of
adequate controls on ISP networks. Is an additional set of records
going to fix a problem that is only a problem because of inadequate
network controls on SMTP server services?
Are we fixing a symptom of a bigger problem? The bigger problem is lack
of accountability. For example, a properly controlled smtp queue can be
limited to only a certain number of messages per day, week, or month.
The billing ISP can bill for excess. If the content, style or type of
message is found to be spam, or viruses, then the offending account can
be charged for the excess or by violation. People respond well to
monetary motivation.
Building something to block unauthorized relaying by SPF or SRV records
is just saying, in a more complex way, hey quit it. When you can
already tell that they are doing it by looking at your local mail queue.
~ So, what is the difference in blocking it with a protocol level service
DNS record in the transport agent or at the network level by service
type and or protocol?
Do we really need something new to regain control? Does the tool that
is necessary to fix the problem already exist?
Also, even if we do build the SPF or SRV record structures and mesh them
into the MTA checks, is it going to save us from the local users abusing
the local smtp relay server? NOPE!
l8r!
.
.
.
O.K. This isn't religion. Whether or not we feel we should be forcing
people to use application layer gateways, many are already doing it. We
do it and no one on our ISP has complained once.
<A BIT OFF TOPIC . . . SKIP IT IF YOU WANT>
We as ISP administrators can force all smtp traffic through a gateway of
our choosing. We can scan mail as it heads outbound, through an
off-site smtp-mta mx proxy virus and spam scanning service (like
Postini), and even on the inbound mail delivery. We can shut down all
smtp traffic out of our ISP's that doesn't source to our outbound
relay. We can force all traffic to/from POP and IMAP servers off-site
to be forwarded through, or picked-up by our servers so that we can scan
the mail that comes in from mail servers off-site. The last and most
important step we can take is to move everone to authenticated SSL
smtp. That will put the nail in the coffin for most of the smtp abuses
on our networks.
As for inter-server communications . . . with the above items in place,
no one should ever see an e-mail from a single soul on our networks that
doesn't come from our mail servers. If every ISP provide services to
their customers and held them accountable for their actions, there
wouldn't be any spammers on the planet. Personally, I believe we are
attacking this from the wrong angle. All ISP's should run a registry of
authoritative smtp servers for themselves. All ISP's should be held
accountable for the actions of their customers. All the SPF and SRV
records are going to do is provide another thing to abuse . . . another
thing to have misconfigured . . . another thing to blame when it doesn't
save us from spam or viruses.
We already have MX records for inbound delivery. If the smtp servers on
the Internet could tell what servers are authoritative relays then there
would not be any discussion. But, if the only relays that were allowed
to operate were authoritative relays then there would be no need for
authoritative records. ISP's can control who operates an smtp server .
. . and they can definitely control the flow of smtp traffic to and from
their networks. If they really did their job there wouldn't be a spam
problem.
So, I do not believe that these new DNS records are going to do anything
but make life more difficult . . . by making one more thing for us to
maintain.
<END PART TO SKIP WHICH IS OFF-TOPIC>
There are those of us who hate the fact the the Internet as we know it
is changing. But, what are we to do? Maybe the SPF TXT records are the
answer . . . maybe the SRV records are the answer. Maybe neither one of
them is the answer. One thing is for certain. It is no longer any fun
to be an administrator when we have to fight the spam and viruses like
we do.
So, quit getting personal. Leave your agendas at the door. Shake
hands, apologize to one another, and let's get back to fixing what is
broken.
Jim Popovitch wrote:
| On Fri, 2003-10-10 at 15:34, Arlie Davis wrote:
|
|> But do you want to be FORCED to use them? My post was not about
|> "can you use a proxy/whatever", but "do you believe that you should
|> be FORCED to use an ISP's application-layer gateways"? I find it
|> hard to believe you don't understand the distinction.
|
|
| First, please don't pretent to know what I do or do not beleive.
|
| I do know that there are many ways to do simple things. I beleive
| that you are trying to do something more difficult than necessary...
| and wanting someone else (in this case other email systems) to put
| their systems at risk for your personal reasons.
|
| -Jim P.
|
|
|
|
|
| ------- Sender Permitted From: http://spf.pobox.com/ Archives at
| http://archives.listbox.com/spf-discuss/current/ To unsubscribe,
| change your address, or temporarily deactivate your subscription,
| please go to
| http://v2.listbox.com/member/?listname(_at_)©#«Mo\¯HÝÜîU;±¤Ö¤Íµø?¡
|
- --
Bryan Campbell . . . bbc(_at_)misn(_dot_)com
STE-MISN 573-775-2111
Key fingerprint: 44AB 0A39 1F4D 0BBE E588 21A7 A4AA B08B AE01 4D39
Key: http://www.misn.com/~bbc/pgp.txt
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.3 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iD8DBQE/h0E0pKqwi64BTTkRAn5EAJ0b0b6AlXQsqbzao2Xg9T5fPN9DOACfSU4k
6m9PPVtYSeliIuChFjlOb8I=
=jPCJ
-----END PGP SIGNATURE-----
-------
Sender Permitted From: http://spf.pobox.com/
Archives at http://archives.listbox.com/spf-discuss/current/
To unsubscribe, change your address, or temporarily deactivate your subscription,
please go to http://v2.listbox.com/member/?listname(_at_)©#«Mo\¯HÝÜîU;±¤Ö¤Íµø?¡