On 10/8/2017 5:51 PM, Rick van Rein wrote:
Hello,
This is a solution for SPF after forwarding and lists that I've been
aware of for a while; I wonder if this is already commonly done?
Forwarding is an action on the receiving end, and can only be solved
reliably by the recipient. Notably, a mailbox user could specify
addresses that are forwarded to their mailbox. Mailing list
subscriptions may be seen as a special form of forwarding.
When incoming mail is SPF-validated and the envelope sender does not
match the sending MTA address, those forwarded domains can be looked up
for the envelope _recipient_ address. Lenient SPF validation would add
permission to sending MTAs from these forwarded domains. The result
would be that forwarding never breaks, when configured on the receiving
mailbox.
I am not sure if this is part of the "mark as NOT spam" procedures in
common mailbox services, but AFAIK it would fix quite a bundle of problems.
I suppose this could also lead to a definition of Lenient DMARC.
Cheers,
-Rick
Hi Rick,
A few highly opinionated points:
Keep in mind that SPF is a PAYLOAD (DATA smtp state) technology. In
other words, it is generally processed, as it was originally intended,
before the DATA smtp state. Therefore, there are limited process
parameters available pre-DATA:
CIP Connection/Client IP address
CDN Client Domain Name (HELO/EHLO)
RP Return Path (MAIL FROM)
FP Forwarding Path (RCPT)
So SPF is basically a function of the CIP, CDN and/or RP and generally
not the FP, however some implementations, lioe ours, do not process
SPF until FP is first acceptable. i.e. no need to perform the SPF
Overhead if the user does not exist or the user or domain is not
locally hosted.
Hence there is no PAYLOAD data to be used in an SPF method unless the
implementation is designed to wait until the DATA is transferred to
begin an SPF. This was a latter design, in particular when Payload
technologies were proposed, like ADSP and "Super ADSP" (DMARC). DMARC
combined SPF, so to support DMARC, your implementation would delay SPF
processing until DATA is transferred. But a key point is that no one
can dictate how/when SPF should be employed during an SMTP session.
High scale optimization is still important.
Since 2003, my statistics showed very early on that 83% of the time,
it would be a high overhead waste because if SPF was to fail at DATA,
it would of also failed at PRE-DATA.
This is where the old Microsoft SPF-clone Sender-ID with its PRA
algorithm came into play where it took the 5322.From into account. It
was a DATA technology and as with my early data analysis, if Sender-ID
failed at DATA, so would SPF at PRE-DATA. It was rare to see the
difference. By far, more overhead in SMTP processing by delaying SPF
and waiting until the potentially wasteful DATA payload was
transferred. It was certainly not optimal. But there were the
conditions where there were false positives.
Finally, what if the bad guy created the Headers you wanted to see?
How can you stop it? When DKIM finally come along (after SPF), it
helped deal with the integrity of the payload AS DEFINED by the
originating author domain (5322.From). But when it was altered by
the 3rd party mailers, it threw the proverbial "wrench" into the
process. How to trust the 3rd party "interfering" system became the
ultimate problem we have been trying to resolve.
At the end of the day, nothing works when the required information
needed to "answer the authorizing question" is not coming from the
authoring/originating domain.
ADSP and its successor, DMARC. all fail because it lacks 3rd party
authorization methods.
ATPS was proposed to augment ADSP to address 3rd party resigners.
Still scratching head why it wasn't carried on to DMARC. It will not
address all scales, but it will for most of them them.
In the mean time, we continue to look for extremely high head PAYLOAD
algorithms that 80% of the time, is just waste when it comes to hard
rejection exclusive SPF policies or 5322.From Policies like ADSP or DMARC.
It is that 20% or less, of dealing with the middle ware list server
that is ignoring SPF, ADSP, DMARC and just blindly altering and
resigning with DKIM. If we allow that, then any 3rd party can do the
same. There is no trust. We don't have an authorization process.
Thats been the dearth of tbe problem of completing this 14+ years of
DKIM R&D project.
We never completed a sound POLICY layer.
--
HLS
_______________________________________________
dmarc mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/dmarc
