headers
David MacQuigg | 9 Mar 2005 03:01

Re: Has the IETF dropped the ball?


At 04:34 PM 3/8/2005 -0500, Bruce Lilly wrote:

>On Tue March 8 2005 11:51, David MacQuigg wrote:
>
> > The public is getting mad as hell about spam.  There *will* be a solution
> > to this problem.  If the IETF doesn't provide it
>
>Spam is a social problem. The IETF is an Engineering group. Engineers
>don't solve social problems (as engineers).

The most rewarding efforts in my career have been when I can solve a 
problem that has social benefit.  That is what has me intrigued by this 
spam problem.  I thought of a solution two years ago ( very much like SPF 
), but not knowing anything about TCP/IP, I allowed myself to be talked out 
of it by the experts.

> > some politicians or
> > bureaucrats will.
>
>Unlikely. They seem to create more problems, such as the aptly
>named CAN-SPAM legislation, which confirms that spammers indeed
>can spam.

I didn't say the solution would work. :>)

> > I may not understand all that is going on in the IETF,
> > but it sure looks like they dropped the ball.
>
>Let's try to objectively and calmly consider which ball you
(Continue reading)

Permalink | Reply | 48 comments |
headers
Carl S. Gutekunst | 9 Mar 2005 06:34

Re: Has the IETF dropped the ball?


David MacQuigg wrote:

> What I would most like to see here is a standard so simple and 
> non-controversial that it need not get all the way to final status 
> before people start following it.  Putting it on the standards track 
> could do this. 

The IETF tried this; it was called MARID (MTA Authorization Records In 
DNS). The original charter was well focused and predicated on the 
assumption that a simple and field-proven solution was close at hand. 
But the effort failed, primarily because (IMHO) the problems of MTA 
authentication and authorization proved difficult to isolate. The 
"simple" solutions crossed more operational boundaries and reached 
deeper into the infrastructure than their authors realized, causing 
controversy among even their most ardent supporters. Solutions that 
truly were simple were ignored for lacking in breadth of scope and "feel 
good" impact.

In short, MARID failed because a simple, non-controversial, and 
all-encompassing solution to Internet Mail Authentication does not seem 
to exist.

Yet progress is being made. I'm going to be making field trials of 
several promising technologies in the next week or two, notably Domain 
Keys and BATV. They don't have big marketing budgets behind them, and 
they aren't panaceas, but they do provide clean solutions to specific 
parts of the problem and are simple to pilot.

I would also like to direct your attention to a marvelous paper by Brett
(Continue reading)

Permalink | Reply | 47 comments |
headers
David MacQuigg | 9 Mar 2005 09:31

Re: Has the IETF dropped the ball?


At 09:34 PM 3/8/2005 -0800, Carl S. Gutekunst wrote:

>David MacQuigg wrote:
>
>>What I would most like to see here is a standard so simple and 
>>non-controversial that it need not get all the way to final status before 
>>people start following it.  Putting it on the standards track could do this.
>
>The IETF tried this; it was called MARID (MTA Authorization Records In 
>DNS). The original charter was well focused and predicated on the 
>assumption that a simple and field-proven solution was close at hand. But 
>the effort failed, primarily because (IMHO) the problems of MTA 
>authentication and authorization proved difficult to isolate. The "simple" 
>solutions crossed more operational boundaries and reached deeper into the 
>infrastructure than their authors realized, causing controversy among even 
>their most ardent supporters. Solutions that truly were simple were 
>ignored for lacking in breadth of scope and "feel good" impact.
>
>In short, MARID failed because a simple, non-controversial, and 
>all-encompassing solution to Internet Mail Authentication does not seem to 
>exist.

My understanding was that MARID broke up because of Microsoft's surprise 
disclosure of very broad patent claims threatening any method that uses IP 
authentication.
  http://podcast.resource.org/rf-rfc/index.html#item0003 - first hand 
account of the "MARID Fiasco"
  <http://www.taugh.com./weblog/patapp.html>http://www.taugh.com./weblog/patapp.html 
- John Levine's analysis of Microsoft's patent claims
(Continue reading)

Permalink | Reply | 43 comments |
headers
Hector Santos | 9 Mar 2005 10:47
Favicon

Re: Site policy vs. HELO


----- Original Message -----
From: "Bruce Lilly" <blilly <at> erols.com>
To: <ietf-smtp <at> imc.org>
Sent: Tuesday, March 08, 2005 6:13 PM
Subject: Re: Site policy vs. HELO

>> When there is a legitimate sender, they will report any
>> issue if it mattered to you.

> Pray tell, when you bounce messages from the sender, how exactly do
> you expect the sender to report the problem?

Wasn't it pointed out this is a commercial product?

People will figure it out.  You did!

A) Send email to the sysop,  a requirement for acceptance.
B) You can go to the Support Web Site
C) You can use the Support Mailing list, and
D) If you don't have time for the bullshit, you can pick up the phone!

In all honesty, at this point, you are not a legitimate sender until I can
explain what happen to you specifically.  (see below)

> This particular problem didn't begin a day, a week, or a month ago.
> The first excerpt that I provided today was from 21 Oct 2004, 11:29
> EDT.  And that wasn't the first time.

Simply blabbing it out doesn't cut it.  I don't believe you unless you show
(Continue reading)

Permalink | Reply | 0 comments |
headers
Hector Santos | 9 Mar 2005 12:30
Favicon

Re: Site policy vs. HELO


----- Original Message -----
From: "Bruce Lilly" <blilly <at> erols.com>
To: <ietf-smtp <at> imc.org>
Sent: Tuesday, March 08, 2005 6:13 PM
Subject: Re: Site policy vs. HELO

> This particular problem didn't begin a day, a week, or a month ago.
> The first excerpt that I provided today was from 21 Oct 2004, 11:29
> EDT.  And that wasn't the first time.

Well I'll be a MONKEY'S UNCLE!

Oh Bruce,  you were BLACK LISTED!!!  TWITTED from sending into our system
with your erols.com domain.

File: wc:\data\ValidateMailFrom.txt
[1    ] reject erols.com
End of File

Case close!

Lets see whats the file date is.... Aug 27 2003.

I knew there was a reason for all this.  I dont' remember why but I must of
got tired of you harassing me at the time sending duplicate messages to me
and the various IETF mailing list.  Let me see what my MUA logs show for
that time frame... Yup. some stupid thread about MUAs and you were all over
my face sending duplicate messages.  In fact, I found a draft email that I
never bother to post that informs you that you were twritted!
(Continue reading)

Permalink | Reply | 6 comments |
headers
Arnt Gulbrandsen | 9 Mar 2005 13:01
Picon
Favicon
Gravatar

Re: Site policy vs. HELO


Hector Santos writes:
> Like I said, there is a reason for everything. Nothing to do with 
> protocols or its reliability. In fact, it was a 100% trusted result.

It's just that the error message did not say so, eh?

Expecting people to report a problem (as you wrote about earlier today) 
is 100% unrealistic when your error message gives them no idea of what 
the problem is. Get real.

Arnt
Permalink | Reply | 4 comments |
headers
Hector Santos | 9 Mar 2005 13:33
Favicon

Re:


----- Original Message -----
From: <owner-ietf-smtp <at> mail.imc.org>
To: <winserver.support <at> winserver.com>
Sent: Tuesday, March 08, 2005 5:28 PM

> On 3/8/2005 11:36 AM, Hector Santos wrote:
>
> > Over the pass year and a half, we have proved that by increasing the
> > level of SMTP compliancy required by senders, you can address an
> > extremely high rejection rate with a very low to non-existence false
> > positives.   100% based on SMTP compliancy.
>
> I'm seeing just the opposite. I've been doing some expirementation with
> some strict SMTP rules in SpamAssassin (looking for things like literal
> HELO, mismatched rDNS, etc), and am getting reports of extremely high
> error rates from testers. [1]

You are not going to get a reliable result performing DNS techniques for
HELO/EHLO.   Thats a given.

I don't see how you can get poor results with testing domain literals.
Either it is correct or its not.

Our HELO tester is quite simple:

1) Test for 2822 ABNF compliance.    - RFC 2822, RFC 2821
2) Domain Literals MUST match the IP - RFC 2821
3) Check for Local Domain Spoofs - RFC 2821
(Continue reading)

Permalink | Reply | 0 comments |
headers
Hector Santos | 9 Mar 2005 14:14
Favicon

Re: Site policy vs. HELO


----- Original Message -----
From: "Arnt Gulbrandsen" <arnt <at> gulbrandsen.priv.no>
To: <ietf-smtp <at> imc.org>
Sent: Wednesday, March 09, 2005 7:01 AM
Subject: Re: Site policy vs. HELO

> Hector Santos writes:
> > Like I said, there is a reason for everything. Nothing to do with
> > protocols or its reliability. In fact, it was a 100% trusted result.
>
> It's just that the error message did not say so, eh?

Right. Because it was an older deprecated filtering logic that was still
active on my system.

> Expecting people to report a problem (as you wrote about earlier today)
> is 100% unrealistic when your error message gives them no idea of what
> the problem is. Get real.

We did get real.  It was a built-in decision long ago to not feed malicious
senders any information that might help them adjust.

If any problem, is that we didn't log it on the server-side and that was
because it was a deprecated filtering feature.

The new system does log it on the server-side. That is what made this whole
thing strange.

Bruce could of easily reported back in Oct 2004, "Yo hector, my mail is
(Continue reading)

Permalink | Reply | 3 comments |
headers
David MacQuigg | 9 Mar 2005 15:30

Re: Has the IETF dropped the ball?


At 09:34 PM 3/8/2005 -0800, Carl S. Gutekunst wrote:

>In short, MARID failed because a simple, non-controversial, and 
>all-encompassing solution to Internet Mail Authentication does not seem to 
>exist.

We don't need an "all-encompassing solution" to be a useful standard.  SMTP 
doesn't encompass authentication, but it is still quite useful.  I would 
*not* expect a shared authentication standard to encompass complex 
algorithms for extracting the purported responsible domain from a set of 
headers.  I *would* expect it to encompass how the results of 
authenticating that domain are communicated downstream.

Can anyone give me an example of a requirement that must be included in a 
shared standard and cannot be written in a way that both sides could live with?

-- Dave

*************************************************************     *
* David MacQuigg, PhD              * email:  dmq'at'gci-net.com   *  *
* IC Design Engineer               * phone:  USA 520-721-4583  *  *  *
* Analog Design Methodologies                                  *  *  *
*                                  * 9320 East Mikelyn Lane     * * *
* VRS Consulting, P.C.             * Tucson, Arizona 85710        *
*************************************************************     *
Permalink | Reply | 1 comment |
headers
Hector Santos | 9 Mar 2005 18:27
Favicon

Re: Has the IETF dropped the ball?


----- Original Message -----
From: "David MacQuigg" <dmq <at> gain.com>
To: "Carl S. Gutekunst" <csg <at> alameth.org>
Cc: <ietf-smtp <at> imc.org>
Sent: Wednesday, March 09, 2005 9:30 AM
Subject: Re: Has the IETF dropped the ball?

> Can anyone give me an example of a requirement that must be included in a
> shared standard and cannot be written in a way that both sides could live
with?

In my view, all the proposals inevitably have the same inherent problem:

    "how do deal with legacy and non-compliant SMTP clients."

SMTP compliancy issues must be addressed first before any of these proposal
even have a chance to work.  It will be extremely difficult to implement a
proposal that accepts/rejects a compliant sender yet at the same time you
still have the operate in the same mode for legacy and non-compliant
senders.

The solution to this seems to be two folds:

- A different set of policies
- Stronger Client/Server negotiation handshaking.

Sincerely,

Hector Santos, CTO
(Continue reading)

Permalink | Reply | 0 comments |

Gmane