ietf-smtp
[Top] [All Lists]

Re: Site policy vs. HELO

2005-03-09 02:55:16


----- Original Message -----
From: "Bruce Lilly" <blilly(_at_)erols(_dot_)com>
To: <ietf-smtp(_at_)imc(_dot_)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
the proof. We have all our logs archived and I intend to analyze all your
transactions.

I will analyze all your transactions for the past two years and see whats
going on.  Something is very strange with your specific transactions.  This
needs to be investigated.

We will do a thorough analysis of your rejections. I should mention, that by
you not reporting this early on, this is NOT the norm.   You didn't report
it so you have a small part of being part of the problem.

Maybe this is pointing out a new unfortunate attitude we need to help put a
halt to - Poor Email Transaction Operations should not be acceptable.  We
have taken it for granted that SMTP compliancy is not a requirement hence we
have the bad transactions/spoofing issues and we have a growing tendency to
just drop mail at will.

Nonetheless, I don't know what your motive is behind all this.

What are you attempting to prove?  What is your point behind all this?
Are you simply saying the
methodology is wrong and unreliable?  Are you saying it is not possible to
apply stronger SMTP transaction management successfully?

I proved otherwise and this mishap with you, whatever is going on, isn't a
measuring stick to throw the baby out with the bath water.

If you want to prove there is a problem with the WCSAP protocol,  I invite
you to use the following URL to test it.  I would love to see false
positives where the SMTP process itself should be aware of.  Again, it is
about SMTP compliancy.  Turn on High Log verbosity to see the complete
details:

        http://www.winserver.com/testwcsap

example input:

        cip        : 207.172.4.61
        cdn        : smtp02.mrf.mail.rcn.net
        from       : blilly(_at_)erols(_dot_)com


I also invite to see our 1.5 years worth of statistics:

        http://www.winserver.com/spamstats

hmmmmmm,  I see you did look at all this back in Oct 21, 2004.  Thing are
starting a little more sense here with missing WCSMTP -> WCSAP log entries.
You used the TESTWCSAP directly in Oct 21, 2004 successfully but you failed
with a SMTP transaction.

I'll be back with the complete analysis.

Sincerely,

Hector Santos, CTO
Santronics Software, Inc.
http://www.santronics.com
305-431-2846 Cell
305-248-3204 Office



<Prev in Thread] Current Thread [Next in Thread>