On Sat, Aug 12, 2023, at 11:48 AM, John Levine wrote:
> It appears that Jesse Thompson <z...@fastmail.com> 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.
The guy presumably rejects based on SPF during MAIL FROM, right? Rejecting due
to DMARC missing SPF alignment would need to wait until DKIM alignment and
other factors are known would need to occur after DATA. Sounds like this could
be spelled out as a best practice, if it isn't.
> 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.
I get that there is a lot of legacy code to support which will take forever to
change. If it's a matter of requiring increased memory overhead (etc) to get
the desired result of being able to consider complete context before issuing
the most appropriate SMTP response after DATA, it is technically possible today
and is in the receiver's best interest to invest in the additional cost of
doing it. Another best practice?
I suppose that if per-RCPT considerations are factored into the SMTP response
after DATA, it implies that senders will be able to achieve the best
interpretation of SMTP response messages by sending to a single recipient per
transaction (which sounds like is needed for some of the potential
implementations for the "identification of the RCPT TO" for fixing DKIM Replay)
Jesse
_______________________________________________
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc
