[Top] [All Lists]

Re: SMTP traffic control

2011-10-13 22:23:45

Claus Assmann wrote:
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?

Thinking about it, initially I would have an issue with the exposure of this information, but then it may not be a problem since a server will be securing its capacity against DoS attacks.

Speaking for our MTA design, we have certain features, although not automated yet, operators can limit their outbound volumes:

     concurrent connections per IP
     multiple transactions per session

from what they they see in the Queue Monitor and transaction results.

So every attempt, for example, has a log entry:

  Total Connections: X  Current IP [A.B.C.D] Connections: Y

The operator can now learn when remote systems begin to show 421 connection results and add a limit fro this site.

Our plan to automate the learning.

So would "Server Capacity" exposure help?

Well, if it was available today, I think currently actively supported adaptive software vendors will consider it.

Mind you, its only an issue when dealing with volume because most systems don't need it.

What is needed though is a a "RETRY=HINT" concept for GREYLISTING because this is what everyone is beginning to see, from small to large.

The RETRY=HINT concept could/would be part of this Server Capability exposure too, but IMTO, it could also be the only result needed for a client as it is the ultimate outcome to assist in scheduling.

If we wanted to know more about server operations, helpful information would be when a SYSTEM HOURS are too as I have seen remote sites where:

  - Accept mail only after hours,
  - Accept in the morning, stop after hours.

and similar behavior.

Finally, its not an odd idea to have "System Hours" exposed as that ideat was par for the course in the Fidonet Mailer era. You were either 24x7 or not and if not, the minimum requirement was 1 hour called the ZONE MAIL HOUR (ZMH) and this was to allow for HOST ROUTING during this period. The following was part of Fidonet Policy 4 document:

10.2  Timing of Zone Mail Hour

Zone Mail Hour is observed each day, including weekends and holidays.  The
time is based upon Universal Coordinated Time (UTC), also known as Greenwich Mean time (GMT). In areas which observe Daylight Savings Time during part of the year, the local time of zone mail hour will change because FidoNet does not observe Daylight Savings Time. The exact timing of Zone Mail Hour is set
for each zone by the Zone Coordinator.

In FidoNet Zone 1, Zone Mail Hour is observed from 0900 to 1000 UTC. In each
of the time zones, this is:

     Eastern Standard Time          4 AM to 5 AM
     Central Standard Time          3 AM to 4 AM
     Mountain Standard Time          2 AM to 3 AM
     Pacific Standard Time          1 AM to 2 AM
     Hawaii Standard Time          11 PM to Midnight

In FidoNet Zone 2, Zone Mail Hour is observed from 0230 to 0330 UTC.

In Fidonet Zone 3, Zone Mail Hour is observed from 1800 to 1900 UTC. In each
of the time Zones involved this is:

  GMT +12 Zone                        6:00 AM to 7:00 AM
  (New Zealand)

  GMT +10 Zone                        4:00 AM to 5:00 AM
  (East Australia)
  (Papua New Guinea)

  GMT +9.5 Zone                       3:30 AM to 4:30 AM
  (Central Australia)

  GMT +9 Zone                         3:00 AM to 4:00 AM
  (Eastern Indonesia)

  GMT +8 Zone                         2:00 AM to 3:00 AM
  (Hong Kong)
  (Central Indonesia)
  (Western Australia)

  GMT +7 Zone                         1:00 AM to 2:00 AM
  (Western Indonesia)

Could we do something like that for Internet Email public port policies?

I seem to doubt it, but who knows. I will note that one of the beauties of migrating to SMTP was that it did REDUCE these advanced scheduling concepts of the early days where channels were more scared (dialup was the norm).

But if some SMTP vendor started it for their own MTAs, you might to see others follow it.

If a remote site is going to REJECT mail until a certain time period, it would help MTAs to reduce the overhead and that helps the general network as well in the long run.


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