On 10/29/2015 2:08 PM, ned+ietf@xxxxxxxxxxxxxxxxx wrote:
Neils, the question is, why is it so hard to set up your own mail server and
have it basically do what you need?
Ted, you keep saying things like this as if they are true. Simply put, they're
not. The obvious counterexample is MS Exchange, which, my personal dislike for
it notwithstanding, is hardly rocket science to install and configure. Lots of
people with very modest technical skills do it routinely. (The place where they
get into trouble is when they outgrow what they originally did, have to upgrade
the hardware, etc. This is where things can get to be a bit of a PITA with MS
Exchange.)
In fact it's the existence of MS Exchange that keeps a lot of vendors from
bothering with this space. (It's absolutely why we started moving away from it
~15 years ago.) Even so, there are other offerings, such as the server IETF
participant Hector Santos works on. Perhaps he can comment on how
straightforward his product is to set up.
...
Since I categorically reject your thesis that initial setup of a simple mail
server is the Hurculean task you claim it is, I have no idea what work the IETF
could undertake to solve this nonexistent problem.
Not sure if this helps... and I have not read the entire thread, I
agree, SMTP is relatively simple. I think a good job was done in this
regard for the IETF "SMTP" default design and operation.
Every package will differ. We are 100% commercial, shrink wrapped,
boxed, CD, etc. So I have always strived for "Customer comes first,"
"Getting it right the first time," high quality, lower TCO,
simplicity, shorter lead time in installation to full operation so my
IETF inputs are generally with that engineering mindset. SMTP is just
the networking part of the integrated application hosting platform (a
BBS for the old school folks), so everything needs to be
installed/setup relatively easy for the non-expert, lower experienced"
administrator, sysop, operator, even "help desk" tech support guy.
Overall, we have to program the IETF output for our customers and for
the most part, I used the sensible "IETF defaults" for "out of the
box" operations. I don't want additional support cost/problems so I'm
very conservative and only support technically logical new things or
changes that can work without trouble and doesn't open additional can
of worms. I also tend to avoid anything that isn't cooperatively
competitive, i.e, I won't support a vendor idea that benefits them or
few only and exerts more trouble for others. For any exploration, I
will add the necessary flexibility, revert switches, etc, if it makes
sense and always, backward compatibility is first.
Server-side p-code compiled scripting allows for programmable hooks
into the hosting platform, including the SMTP process. Threaded slave
calls are made at each SMTP state. SPF is processed at RCPT state to
begin processing the collected client IP, EHLO, MAIL FROM and RCPT TO
SMTP level session parameters. A YES/NO (250/550) response at RCPT.
Greylisting, DKIM, ADSP, ATPS and now DMARC is processed at DATA
state. A 250/45x/55x) response at DATA. SPF FAIL Rejects are done at
SMTP before DATA. All this extra processing is important because it
points to the increased SMTP overhead that we experience that can
affect scaling needs. What is the industry new average increase
session time? For my site where I have everything enabled, its about
1-5 seconds or more.
Finally, in regards to the DMARC parts of this thread. I see more DKIM
related changes that has a high potential for more overhead, more
processing, more waste and work, i.e, double DKIM signature
processing. I am not a fan of the 5322 rewriting idea. It has the
potential to conflict 5322.From stable platform designs. But I will
explore the "controls" that can be added or that may already exist.
--
HLS