Re: Paul's Mailfrom (Was: IETF SMTP Working Group Proposal at smtpng.org)

2002-08-28 Thread David Schwartz
On Thu, 29 Aug 2002 00:48:39 +0200, Brad Knowles wrote: >At 6:13 PM -0700 2002/08/27, David Schwartz wrote: >>I'm afraid the technology to rapidly sift through large volumes of >>information to search for specific areas of interest is widely available. >Really? Where? I'd like to kn

Re: Paul's Mailfrom (Was: IETF SMTP Working Group Proposal at smtpng.org)

2002-08-28 Thread Lyndon Nerenberg
> > The Internet is a peer-to-peer network, whether you like it or not. > > That's changing, whether you like it or not. No it isn't. What _has_ changed is that the network is now run by the marketing department. --lyndon

Re: Paul's Mailfrom (Was: IETF SMTP Working Group Proposal at smtpng.org)

2002-08-27 Thread David Schwartz
On Tue, 27 Aug 2002 19:40:16 -0700, Jim Hickstein wrote: >--On Tuesday, August 27, 2002 6:13 PM -0700 David Schwartz ><[EMAIL PROTECTED]> wrote: >>I'm afraid the technology to rapidly sift through large volumes of >>information to search for specific areas of interest is widely available.

Re: Paul's Mailfrom (Was: IETF SMTP Working Group Proposal at smtpng.org)

2002-08-27 Thread David Schwartz
>>Maybe I don't want my email sitting around in your MTA queue for >>your sysadmins to read. >Given the volumes of mail that pass through these kinds of >things, that's not likely to be a problem. More likely to be a >problem would be the fact that the mail might sit there for a week >befo

RE: Paul's Mailfrom (Was: IETF SMTP Working Group Proposal at smtpng.org)

2002-08-27 Thread Barry Shein
From: JC Dill <[EMAIL PROTECTED]> >I guess you haven't read RFC 3098 yet then. > >http://www.geektools.com/rfc/rfc3098.txt Wow, I missed that. It's really quite good. So good, in fact, that I just sent copies of it out to the 300 MILLION ADDRESSES I have on this CD here... No, seriously, it's

Re: Paul's Mailfrom (Was: IETF SMTP Working Group Proposal at smtpng.org)

2002-08-27 Thread Lyndon Nerenberg
> So what's so bad about forwarding all tcp/25 traffic over that relay and > letting that relay decide if the MAIL FROM: is allowed to be relayed? Because I want to send mail through my own SMTP server that speaks STARTTLS and uses certificates that are under my control. Maybe I don't want my e

Re: Paul's Mailfrom (Was: IETF SMTP Working Group Proposal at smtpng.org)

2002-08-27 Thread michael . dillon
Filters are static things, that have to be updated, and can't see every case that comes thru. It might be possible to make filters that don't need to be updated that often if you apply AI techniques to recognizing SPAM. For instance, check out this new approach: http://www.paulgraham.com/pau

Re: Paul's Mailfrom (Was: IETF SMTP Working Group Proposal at smtpng.org)

2002-08-26 Thread John M. Brown
Barry, I have a wrench :) Everything looks like a nut to me. But in all seriousness. I have to agree with Barry's statement here. Spam is very much a social, political, ethical, and financial issue. Filters are static things, that have to be updated, and can't see every case that comes thru.

Re: Paul's Mailfrom (Was: IETF SMTP Working Group Proposal at smtpng.org)

2002-08-26 Thread Paul Vixie
> as joe pointed out to me privately RFC 2782 specifies SRV RRs which could be > used to point an MX.SRV at a port other then 25. anyone got any examples of > MTAs or MUAs that implement said RFC? actually it would be _smtp._tcp.$DOMAIN but it's not in use for e-mail. or web, even though that's

Re: Paul's Mailfrom (Was: IETF SMTP Working Group Proposal at smtpng.org)

2002-08-26 Thread Martin
$author = "John Kristoff" ; > > On Tue, Aug 27, 2002 at 12:14:46PM +1000, Martin wrote: > > but surely an MTA derives it's usefulness by running on port 25. i don't > > remember reading about where in the DNS MX RR you could specify what port > > the MTA would be listening on... > > Surely your

RE: Paul's Mailfrom (Was: IETF SMTP Working Group Proposal at smtpng.org)

2002-08-26 Thread Vivien M.
> -Original Message- > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] On > Behalf Of Martin > Sent: August 26, 2002 10:15 PM > To: [EMAIL PROTECTED] > Subject: Re: Paul's Mailfrom (Was: IETF SMTP Working Group > Proposal at smtpng.org) > > but surel

Re: Paul's Mailfrom (Was: IETF SMTP Working Group Proposal at smtpng.org)

2002-08-26 Thread John Kristoff
On Tue, Aug 27, 2002 at 12:14:46PM +1000, Martin wrote: > but surely an MTA derives it's usefulness by running on port 25. i don't > remember reading about where in the DNS MX RR you could specify what port > the MTA would be listening on... Surely your not a spammer looking for tips are you? :

Re: Paul's Mailfrom (Was: IETF SMTP Working Group Proposal at smtpng.org)

2002-08-26 Thread David Schwartz
>Force forward by default, but allow anyone who wants to use TCP port >25 the ability to do so. They must sign an non-abuse agreement or >whatever. Then they get their host/link put into the TCP port 25 open >path. Every ISP I have ever worked for and every ISP I have ever used has ev

Re: Paul's Mailfrom (Was: IETF SMTP Working Group Proposal at smtpng.org)

2002-08-26 Thread Martin
$author = "John Kristoff" ; > > I'm not sure how to truly disable an SMTP server from running on an end > host. You can block or force forward port 25, but that is just a > number. Be prepared to start doing that for all ports, then protocols, > then IP addresses, then protocols again. but su

Re: Paul's Mailfrom (Was: IETF SMTP Working Group Proposal at smtpng.org)

2002-08-26 Thread John Kristoff
On Tue, 27 Aug 2002 01:54:39 +0200 "Jeroen Massar" <[EMAIL PROTECTED]> wrote: > SMTP is a protocol which is based on relaying messages from one > mailserver to another. > An endnode (especially workstations) don't need to run SMTP. I'm not sure how to truly disable an SMTP server from running on

RE: Paul's Mailfrom (Was: IETF SMTP Working Group Proposal at smtpng.org)

2002-08-26 Thread JC Dill
On 03:07 PM 8/26/02, Barry Shein wrote: >Let me throw out the following to show how blind the technical >community has been: > > There is no RFC or other public standards document which even attempts > to define spam or explain, in a careful and professional manner, > why it is a bad thi

RE: Paul's Mailfrom (Was: IETF SMTP Working Group Proposal at smtpng.org)

2002-08-26 Thread Barry Shein
On August 27, 2002 at 00:59 [EMAIL PROTECTED] (Jeroen Massar) wrote: > We didn't invent stuff like SMTP, POP3, IMAP and stuff to be run on > EVERY single node on the internet. Actually, I think we did. Unfortunately it turned out to be a really, really, bad decision. -- -Barry She

RE: Paul's Mailfrom (Was: IETF SMTP Working Group Proposal at smtpng.org)

2002-08-26 Thread Jeroen Massar
John Kristoff wrote: > On Tue, 27 Aug 2002 00:59:49 +0200 > "Jeroen Massar" <[EMAIL PROTECTED]> wrote: > > Nice rant Randy, but if you even ever wondered why the wording "Mail > > Relay" exists you might see that if an > > ISP simply forwards all outgoing tcp port 25 traffic to one of their > >

Re: Paul's Mailfrom (Was: IETF SMTP Working Group Proposal at smtpng.org)

2002-08-26 Thread John Kristoff
On Tue, 27 Aug 2002 00:59:49 +0200 "Jeroen Massar" <[EMAIL PROTECTED]> wrote: > Nice rant Randy, but if you even ever wondered why the wording "Mail > Relay" exists you might see that if an > ISP simply forwards all outgoing tcp port 25 traffic to one of their > relays and protects that from weir

Re: Paul's Mailfrom (Was: IETF SMTP Working Group Proposal at smtpng.org)

2002-08-26 Thread Scott Gifford
Brad Knowles <[EMAIL PROTECTED]> writes: [...] > Moreover, even if all servers on the Internet were secured in > this manner and there were no open relays, it would also require > perfect reverse DNS because the MXes are listed by name and not IP > address -- that's assuming you do a reve

RE: Paul's Mailfrom (Was: IETF SMTP Working Group Proposal at smtpng.org)

2002-08-26 Thread Jeroen Massar
Randy Bush wrote: > >> ISP's should actually block port 25 outgoing, or even better, > >> reroute/forward it to their own mail relay. > > Agreed. > > why not do it to port 80 as well? what the hell, why not do it to all > ports? who the hell needs an internet anyway, let's all have a telco

Re: Paul's Mailfrom (Was: IETF SMTP Working Group Proposal at smtpng.org)

2002-08-26 Thread Scott Gifford
David Van Duzer <[EMAIL PROTECTED]> writes: > On Mon, 2002-08-26 at 15:47, Scott Gifford wrote: > > > > The problem that this deals with is the user who needs to dial in to > > AOL and send mail from their corporate account. The proposed solution > > is to tunnel mail through the corporate ser

Re: Paul's Mailfrom (Was: IETF SMTP Working Group Proposal at smtpng.org)

2002-08-26 Thread Scott Gifford
David Van Duzer <[EMAIL PROTECTED]> writes: [...] > The presumably appropriate topic for discussion on this list is why > a system such as this would be a problem for network operators who > choose not to implement such a callback feature. So far the only > objection I've seen is "It won't mak

RE: Paul's Mailfrom (Was: IETF SMTP Working Group Proposal at smtpng.org)

2002-08-26 Thread Jeroen Massar
[EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] wrote: > On Mon, 26 Aug 2002 21:12:40 +0200, Jeroen Massar > <[EMAIL PROTECTED]> said: > > IMHO, Paul's idea is quite a good one, but all servers will need to be > > upgraded, and all dns entries installed. > > Given the number of providers who see

Re: Paul's Mailfrom (Was: IETF SMTP Working Group Proposal at smtpng.org)

2002-08-26 Thread Valdis . Kletnieks
On Mon, 26 Aug 2002 21:12:40 +0200, Jeroen Massar <[EMAIL PROTECTED]> said: > IMHO, Paul's idea is quite a good one, but all servers will need to be > upgraded, and all dns entries installed. Given the number of providers who seem to think ingress and/or rfc1918 filtering shouldn't be done, what

Paul's Mailfrom (Was: IETF SMTP Working Group Proposal at smtpng.org)

2002-08-26 Thread Jeroen Massar
Paul Vixie wrote: > [EMAIL PROTECTED] (Martin Cooper) writes: > > > OK - but unconditionally permitting null-return paths means that > > spammers can drive a coach and horses through the hole it > leaves. :-( > > that's how the proposal is optional. spammers who lie about their > source/retu