It appears that Jesse Thompson <[email protected]> said: >> This of course requires that the recipient SMTP server can't simply >> reject the incoming email after the MAIL FROM because SPF checks do >> not match, they actually need to receive the email so they can check >> ARC and DKIM headers... > >During my 19 year career we used software built by Ned Freed. It was perfectly >capable of evaluating full content (as well as >integrating with 3rd party evaluation software) and return an appropriate SMTP >response after DATA. Why is it still so difficult?
I am in yet another argument with a guy who is complaining that he's not getting forwarded mail, I point out that he's rejecting on SPF failure so that's not a bug, it's what he has told his system to do, and he insists it's my fault. For some reason this attitude is unusually common in mail systems in central Europe. To reiterate the obvious, you can't do DMARC without processing the entire message during the SMTP session at least enough to check the DKIM signatures. No sensible mail system rejects on SPF failure (other than bare -all for no mail), because the error rate is so huge. A very long time ago people tried to minimize the work in the SMTP daemon because there were small fixed size connection tables and on systems without shared libraries, many copies of the daemon could cause a lot of swapping. These days the connection table never fills up, my SMTP daemon uses about 30 shared libraries, and my decade old server can handle 100 connections and barely notices the load. So, yeah, you can do it all in the SMTP daemon and in practice everyone does now. R's, John _______________________________________________ dmarc mailing list [email protected] https://www.ietf.org/mailman/listinfo/dmarc
