I think there are three cases of interest
1) There is no profile information for the domain
2) There is profile information for the domain and the use
is consistent
3) There is profile information for the domain and the use is not
consistent
Probably the same category, as #3 but you may have:
4) There is inconsistent mixed profile information (one for
return path, one
for helo).
I see this alot and it may say something about the forwarding
mail probem.
If a return path profile fails, could a pass HELO profile prevail?
As I see it there are three possibilities for EACH of the identities
that might be tested. Now that opens up a lot of possibilities but
in practice you are likely to work at EITHER the 2821 level OR the
2822 message level at a given time. The point about the 2821 checks
is that if you fail them you are not going to make it to the 2822
checks, you will just be /dev/nulled.
I would divide 3 up into 3 possible sub-cases:
3a) Both 2821 HELO and FROM are inconsistent
3b) 2821 HELO is consistent but FROM is inconsistent
3c) 2821 FROM is consistent but HELO is inconsistent
What the receiver decides to check is not relevant here, the receiver's
decision on what to check will depend on what they do with the information,
if they are going to reject anyway lazy evaluation obviates need for test.
It is pretty easy to decide what to do for case 3a), the message
is rejected.
I think the treatment of cases 3b and 3c should probably be decided
by looking at some statistics. It may be a shades of grey thing, it
may simply be misconfiguration of HELO.
Phill