Hi,
I haven't enabled enforcing DMARC rules in wcSMTP; it simply logs and
records issues, and the result is the same: failures due to
third-party involvement.
On the sender side, I’m ensuring that my wcSMTP implementation is
robust enough for my customers to pass the SPF/DKIM checks mandated by
ADSP—oops, I mean DMARC baloney. At this point, it's become necessary
to have provisional scripts in place for rewriting and resigning
outgoing mail.
ADSP failed because there were no viable third-party solutions. So why
should we expect Super-ADSP, aka DMARC, to work any better for third
parties? It doesn't, so it's essentially the same as ADSP—the same
issues then, the same issues now.
Have a great 2025! :-)
On 1/3/2025 1:58 PM, Michael Thomas wrote:
On 1/2/25 7:45 PM, Barry Leiba wrote:
And in addition to the draft's being clear that receivers need to
check all of the authentication mechanisms (currently SPF and DKIM),
Section 7.4 contains strong language that senders relying on SPF
alone, without DKIM, are treading dangerously. The combination --
senders really need to sign with DKIM, receivers need to check both
SPF and DKIM -- is important, and anyone who thinks we need to say it
more clearly should please send suggested text so we can see
specifically what we need to add/clarify.
I think it's a little more than "treading dangerously". It sort of
goes to the heart of why DMARC exists at all.
Didn't Tero say that there used to be a MUST somewhere that made
explicit that both SPF and DKIM MUST be evaluated? If so, why was
it taken out and why can't it be put back in to clear his issue?
There is a like absolutely no rationale for receivers to not verify
DKIM these days. Even 20 years ago it wasn't an issue.
Mike
Barry
On Thu, Jan 2, 2025 at 9:40 PM John Levine <[email protected]> wrote:
It appears that Michael Thomas <[email protected]> said:
If we are going under the assumption that both SPF and DKIM have
their
own strengths and weaknesses with respect to being able to verify
where
a piece of email came from (or passed through too in the case of
DKIM),
a sender needs the confidence that the receiver implement both of
them
before they set a reject policy which could lead to deliverability
issues. It is utterly irrelevant what is currently deployed in
the field
right now -- it's a new proposed standard, after all. Both SPF
and DKIM
have their own policy mechanisms and if you are a SPF-only shop
you can
use its mechanism if you feel brave enough.
That is both what 7489 says and what the current draft says. Every
DMARC
implementation I know checks both SPF and DKIM. We considered and
rejected
proposals to deprecate SPF, or to add a flag saying to check only
one or the other.
If you think the draft needs changes, it'd be helpful if you could
send text.
R's,
John
_______________________________________________
dmarc mailing list -- [email protected]
To unsubscribe send an email to [email protected]
_______________________________________________
dmarc mailing list -- [email protected]
To unsubscribe send an email to [email protected]
--
Hector Santos,
https://santronics.com
https://winserver.com
_______________________________________________
dmarc mailing list -- [email protected]
To unsubscribe send an email to [email protected]
