[Top] [All Lists]

RE: SMTP traffic control

2011-10-24 06:32:20

I know most major ISPs already provide that kind of data.  It's not difficult 
with existing response codes.  Granted they're not in a standard format (across 
ISPs). Given that any sender could mimic the types of response codes the ISPs 
are using, but haven't, what level of success can we really expect after a 
standardization effort?

"Murray S. Kucherawy" <msk(_at_)cloudmark(_dot_)com> wrote:

-----Original Message-----
From: owner-ietf-smtp(_at_)mail(_dot_)imc(_dot_)org 
[mailto:owner-ietf-smtp(_at_)mail(_dot_)imc(_dot_)org] On Behalf Of Claus 
Sent: Thursday, October 13, 2011 10:22 AM
To: SMTP Interest Group
Subject: Re: SMTP traffic control

It would be nice to have a standard for a server to tell a client
which restrictions it triggered, what the limits are, and what it
should do to avoid this from happening again. For example:

- number of sessions per time unit
- concurrent number of sessions
- number of transactions per session

It would also be helpful to have an enhanced status code that tells
a client: "don't even try one of the other MXs, it will reject you
too." That can be rather helpful for greylisting and for systems
that share traffic control information.

Anyone interested in specifying this?

Knowing which MTAs you represent, I'm curious: Are these napkin scratchings of 
things that might be neat or useful to have, or are you responding to consumer 
pain points?

If the latter, knowing the background of these ideas might go a long way to 
justifying the work and, of course, having faith that there will be a ton of 
interoperability shakedown, which makes for a solid specification.


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