Re: Google threatens to break Gmail {dkim-fail}

On 10/29/2015 2:08 PM, ned+ietf(_at_)mauve(_dot_)mrochek(_dot_)com 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