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)
(Micronesia)
GMT +9.5 Zone 3:30 AM to 4:30 AM
(Central Australia)
GMT +9 Zone 3:00 AM to 4:00 AM
(Japan)
(Korea)
(Eastern Indonesia)
GMT +8 Zone 2:00 AM to 3:00 AM
(Hong Kong)
(Taiwan)
(Central Indonesia)
(Philippines)
(Western Australia)
GMT +7 Zone 1:00 AM to 2:00 AM
(Malaysia)
(Singapore)
(Thailand)
(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.
--
HLS