ietf-smtp
[Top] [All Lists]

Re: Fixing graylisting [was TBR]

2007-11-15 15:56:48

John,

I can see your point, and I don't disagree.

My philosophy is such we have the same problem regardless of the "add-on" protocol. Of course, if our goal is to reduce the bad guy issues, then enforcement ideas are required. But as long as legacy operations is fundamental requirement (on the public PORT 25), we will always have a "bad guy" problem exploiting the legacy designs including those with add-ons.

In regards specifically with GL, I too was skeptical and I too did not want to introduce a "mickey mouse" kludge in our system, but if there are customers demands for it, well, you have to provide it and when we did, as I mentioned, everyone jaws dropped at how well it worked.

In my view, I can attribute the "acceptance" to the idea that we don't cater to the public market place, our software is very much dedicated to customers who have two types of message - good and bad and the rates are that the BAD is really BAD and the GOOD is really GOOD with very low "impact" (reports of issues). Anything that causes or increase our support cost is quickly reconsidered and addressed.

But as I also said, it was immediately apparent you need to change to the variable retry frequency with a shorter 2nd retry and most definitely you need to incorporate an auto whitelist concept to quickly get your "network" of good guy customers on the list, etc. If you send an email to someone, it is automatically white list. That includes announcements.

I can agree that any protocol can help induce an increase of bulk senders, but I wouldn't blame it on the protocol. I would venture to say they are also trying to pressure a system of lowering their guards.

I feared the same exact increase issues with 822 based protocols such as DKIM especially when its becomes widely adopted. I already stated this a few times. Bad guys can begin to make the payload MUCH higher to cause scalability issues and with increase sending, that can become a problem. If there isn't a solution, an operator may be forced to turn off DKIM verification. I haven't seen any consideration or discussion in the DKIM WG regarding the hashing of large attachments and the overhead associated with that.

But is that going to be a show stopper? I doubt it and in fact, mostly completely ignored, specially if I am the one making this statement. :-)

--
HLS

John C Klensin wrote:
Hector,

I disagree.   I would construe this situation as one in which we
are making the bad guys smarter, driving up our costs for
detecting them and their products.  I have trouble considering
that a benefit.

A medicine that makes a bacterium or virus treatment-resistant,
especially when we lack treatments for the resistant forms
and/or when the resistant forms are move virulent and deadly
than the originals, is not a completely desirable treatment or
mechanism.

    john


--On Thursday, 15 November, 2007 15:44 -0500 Hector Santos
<hsantos(_at_)santronics(_dot_)com> wrote:

Douglas Otis wrote:
 >
 > Bulk emailers are often anxious to complete their campaigns
and are
 > dubious about retry delays of 30 minutes.  The initial
benefit of
 > grey-listing was as a test for whether a transmitting MTA
carried
 > state since many bots did not.  This is changing where now
many
 > bots retry the same message.  The benefits from grey-listing
 > are fading, while bulk emailers have become more aggressive
in
 > their retries.

That's good Doug.

Good medicines are the ones where you won't eventually need it
anymore.

Good medicines also helps separate the bad from the good from
a compliance standpoint, so if the Bulk mailers are getting
better at what they were suppose to do in the first place,
then thats good. Not bad.

In the mean time, for the systems who don't follow the specs,
GL and other SMTP compliance-based ideas will continue to be
effective.

So your statement about "fading", true or not, I see that as a
positive, not a negative sign that well it worked.








--
Sincerely

Hector Santos, CTO
http://www.santronics.com
http://santronics.blogspot.com

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