On a SPF validation error from mail sent "on behalf of" (RFC 5322 and 5321) #170
Description
I see "on behalf of" e-mail written in the following three different ways:
One
From: "On behalf of [email protected] " [email protected]
Two
From: "Display Name" [email protected] (on behalf of [email protected])
Three
From: "Original Author" [email protected]
Sender: "Agent Name" [email protected]
I mostly see type one, and it is the object of this note.
Headers:
From: "On behalf of: [email protected]" [email protected]
Received: from relay-az-nit001.cert.legalmail.it (relay-az-nit001.cert.legalmail.it [185.34.250.5]) [...]
Authentication-Results: omitted.com;
...
spf=temperror smtp.mailfrom=[email protected] smtp.helo=relay-az-nit001.cert.legalmail.it;
...
Received-SPF: temperror
(cert.infocamere.it ... _spf-legalmail.infocert.it: Time-out on DNS 'TXT' lookup of '_spf-legalmail.infocert.it')
receiver=omitted.com;
identity=mailfrom;
envelope-from="[email protected]";
helo=relay-az-nit001.cert.legalmail.it;
client-ip=185.34.250.5
SPF RRs:
cert.infocamere.it has TXT record "v=spf1 include:_spf-legalmail.infocert.it -all" (insecure)
_spf-legalmail.infocert.it has TXT record "v=spf1 ip4:185.34.250.4 ip4:185.34.250.5 -all" (insecure)
legalmail.it has TXT record "v=spf1 include:_spf-legalmail.infocert.it -all" (insecure)
Comments:
The e-mail claims to be from two entities.
Is sender2.com authorised to send e-mail from 185.34.250.5?
As sender2.com claims to be sending on behalf of sender1.com, where does sender1.com state that sender2.com is authorised to do so?
Both relevant SPFs must exist and be verified. Anyone could send e-mail on behalf of anyone else otherwise.
In this case, they exist.
What I see from the above SPF validation is a clearance check from sender1.com only.
The Milter did not check whether sender2.com was allowed to send from 185.34.250.5.
On the available SPF validation, the Milter timed out when reading from the DNS. Is this a problem with the Milter or with the DNS server? I can say that the timeout is not systematic, as other e-mails get through, so the Milter is working most of the time, but we still need diagnostic information on edge cases like this one, or we shall never know where the problem really is. It certainly is odd when your read a Milter timeout, you check manually and find out that the DNS is responding, and you did this immediately after the timeout was reported. Did the Milter fail? Did it wait long enough? Can I read the detail from the log and set a relevant DNS timeout for the Milter?
This is the relevant setting:
"dns_resolvers" : [ "192.168.1.6" ],
"dns_timeout" : 10,
"cache_dns_timeouts" : 1,
"dns_retry" : 2,
"dns_servfail_timeout" : 1000000,
I am using unbound as local resolver to speed up dns queries.
Update:
I spotted a 14 seconds deley in dns resolution for a domain, so the default 10 seconds above is too low. I am now using the following configuration, hoping it will be sufficient.
"dns_resolvers" : [ "192.168.1.6" ],
"dns_timeout" : 20,
"cache_dns_timeouts" : 0,
"dns_retry" : 5,
"dns_servfail_timeout" : 1000000,
The problem of how to enable SPF validation also for sender2.com is still pending.
Update:
I received another time-out on DNS 'TXT' lookup, for a domain served by cloudflare. As other emails went through, the milter and unbound are working. The fact remains that a 20 seconds delay, with 5 retries, was not enough for a response in this case.
Ref. AM version 4.20250811 from CPAN