Postfix already has a configuration page for SPF [0], albeit requiring a
package from universe. So although removing the SPF snippet from Exim
could be an option in the short-term, I do think in the long-term
Ubuntu's SPF support for Exim should be somewhat equivalent to that of
Postfix's.
Adding
Given that we're at LTS+1, this would seem to be a good point for a re-
think on this piece of delta. I also think Dominic makes good points in
comments #43 and #45, and the course of action seems logical to me as
well. The delta's been proving time-intensive to maintain, and changes
upstream
Option three would be to remove the spf section completely until a non-
broken sustainable solution is implemented, especially if libspf2 is
going to take some time to implement.
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
I agree. I think we may have a case to do libspf2 inclusion, I'll be
happy to start investigating that package and situation a bit deeper
next week.
For now, the default SPF code in mantic/noble is broken out of the box
and I'm not sure which solution (calling bash, removing the quote macro)
I
Thank you, I would appreciate you reiterating the case for libspf2.
Aside from the fact that this implementation is looking (recurrently)
fragile, this Ubuntu delta, disabled by default, is probably not getting
enough attention to spot bugs. This bug has been open for three months
and only one
I'll ask internally again, but the original reasoning why we deviated
from debian is explained at https://bugs.launchpad.net/bugs/1952738
It is definitely open to discussion, and these woes with the parser can
help justify it.
--
You received this bug notification because you are a member of
It was floated before but it's worth raising again. What are the chances
of bringing libspf2 to main and falling back into line with Debian?
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/2056372
I ran `sudo exim4 -bd -d+all` on my server and sent myself an email with
the current config in noble to see what the errors look like, and I get
a ton of information, it looks like the parsing worked correctly at
least (argv[6]).
23:35:50.263 410533 direct command:
23:35:50.263 410533 argv[0] =
One extra thing I tried, is to use the condition check logic Jammy is
using by default (which I tested a jammy system does have working SPF),
except I added preexpand like [0] mentions to use the "old" parsing
method. This didn't work, but just putting my attempt here for future
reference:
Thanks for clarifying, I misread what you meant, now I understand.
I was looking through https://github.com/Exim/exim/blob/master/doc/doc-
txt/ChangeLog to see if there were any other changes between version
4.95 and 4.96 and I don't see much else other than JH/24.
Currently I think that [0] and
No, I was not invoking bash, I was using the code I quoted previously
and testing the scenarios at port 25.
An empty $sender_address variable would create a missing argument and
likely break spfquery.mail-spf-perl, I haven't tested that scenario yet.
$sender_host_address should always be present
** Changed in: exim4 (Ubuntu)
Assignee: (unassigned) => Mitchell Dzurick (mitchdz)
** Also affects: exim4 (Ubuntu Noble)
Importance: Undecided
Status: New
** Also affects: exim4 (Ubuntu Mantic)
Importance: Undecided
Status: New
** Changed in: exim4 (Ubuntu Mantic)
Thanks for doing some testing around the quotes, was that with using
/usr/bin/bash?
Also the lead I had was the changelog entry from upstream:
JH/24 The ${run} expansion item now expands its command string elements after
splitting. Previously it was before; the new ordering makes handling
Good find, I am still running my ${quote:}-less version at the moment so
I was able to test the scenarios in that bug report.
All three of the following senders were correctly rejected as spf fail
by my server (example.com hard fails all senders in its spf record):
MAIL FROM: "$PWD"@example.com
I have a few leads I want to investigate, will report back once I do
some testing.
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/2056372
Title:
Enabling SPF checks with CHECK_RCPT_SPF doesn't work
I was also thinking about similar things.
FYI - I did find out why ${quote:} is being used -
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=697057
** Bug watch added: Debian Bug tracker #697057
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=697057
--
You received this bug notification
Thinking more about this, wouldn't invoking /bin/bash actually increase
the attack potential, by allowing for backticks and $() to execute via
user-supplied data?
Also, it's not clear to me that ${quote} escapes backticks or $().
--
You received this bug notification because you are a member of
I'll do a bit of git archaeology tomorrow to try and find out why the
quote macros were added. Otherwise, my vote is to go with the bash
invocation in the sub-process so that way we can keep the quote macros.
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is
I agree, I also do not know the potential risks of removing ${quote:}
from tainted variables, so this needs further research before
implementation. Or we go with yours.
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
With this said, I have reservations about removing a quote macro without
research. It does more than just quote wrap a variable, it also escapes
quotes and other special characters from the variable
To be honest, I'm no expert in this source code, but if the variables
$sender_host_address or
Nice catch, I like that updated version better. This also leads more
credence to an issue with parsing.
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/2056372
Title:
Enabling SPF checks with
Hi Mitchell,
Your version works for me as well.
In the interim I have been successfully using the following
configuration. Would this be potentially useful, or are there issues
with removing ${quote:} from --ip and --identity?
condition = ${run{/usr/bin/spfquery.mail-spf-perl \
I think I have found a fix for this issue.
My hunch is there is something buggy about the run{} command when
invoking programs directly. I wrapped the contents of run with an
explicit shell invocation, e.g.
condition = ${run{/usr/bin/spfquery.mail-spf-perl \
I have reproduced this issue on a live noble server running exim4.
Digging deeper now.
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/2056372
Title:
Enabling SPF checks with CHECK_RCPT_SPF doesn't
Apologies for the delay, I'm picking this back up today.
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/2056372
Title:
Enabling SPF checks with CHECK_RCPT_SPF doesn't work
To manage notifications
** Changed in: exim4 (Ubuntu)
Status: New => Triaged
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/2056372
Title:
Enabling SPF checks with CHECK_RCPT_SPF doesn't work
To manage
Re-marking as new since I've supplied all requested information.
** Changed in: exim4 (Ubuntu)
Status: Incomplete => New
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/2056372
Title:
Hi, just want to add a quick comment that I’m on vacation until the end
of the week so don’t expect a reply from me until then. Also will be
attending the Canonical sprint next week so might not be able to update
this next week either.
Feel free to take a stab at this if you are triaging this bug
(and comment #6)
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/2056372
Title:
Enabling SPF checks with CHECK_RCPT_SPF doesn't work
To manage notifications about this bug go to:
No, you should be seeing a header. Are the steps you followed the same
as that which I wrote in comment #5 of this report?
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/2056372
Title:
Enabling SPF
That could be a possibility.
On a side note, I tried to setup a testbed to reproduce this (and start
working on a dep8 test) and can't seem to get the setup working
correctly. I followed the steps in bug #1998678, see the mail in
`/var/mail/ubuntu` but don't see any Received-SPF headers at all,
No errors in /var/log/exim4/mainlog, just normal mail flow logs.
I suspect some sort of error was introduced in the code for the #1998678
fix.
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/2056372
I was looking into bug #1998678 as a potential reason, do you see any
concerning logs in your /var/log/exim4/mainlog (or wherever your logs
are)?
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/2056372
Possibly related to:
https://bugs.launchpad.net/ubuntu/+source/exim4/+bug/1998678
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/2056372
Title:
Enabling SPF checks with CHECK_RCPT_SPF doesn't work
It was a clean install of Noble, for some reason the spf check always
returns "none". It is very easily reproducible, as per my comment #5.
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/2056372
Dominic, did you upgrade to mantic and start seeing this failure, or did
you make a new mantic install and set things up from scratch?
I wonder if some logic elsewhere was changed in Debian that we missed,
or has this always been broken?
This scenario would also be a nice thing to have a dep8
Still an issue in noble / 24.04.
"Received-SPF: none" is reported in the headers of received mail for
senders known to have an spf record configured.
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
Also, this should not be marked as "incomplete" as I have supplied all
the required information.
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/2056372
Title:
Enabling SPF checks with CHECK_RCPT_SPF
I get the correct result when running spfquery.mail-spf-perl manually.
$ /usr/bin/spfquery.mail-spf-perl --ip 40.92.113.65 --scope mfrom --identity
exam...@outlook.com
pass
outlook.com: Sender is authorized to use 'exam...@outlook.com' in 'mfrom'
identity (mechanism
Hello Dominic,
The fact that you get that
Received-SPF: none
headers means that spf-tools-perl gets called by exim4. What I suggest
to debug this is to manually call spfquery.mail-spf-per with the
relevant parameters (see the spfquery.mail-spf-perl manpage), and check
if what kind of reply
According to the exim4 changelog, the spf logic was modified in Aug
2023.
exim4 (4.96-17ubuntu1) mantic; urgency=medium
* Merge with Debian unstable (LP: #2030098). Remaining changes:
- Disable external SPF support to avoid Build-Depends on libspf2-dev
(only available in universe).
I'm using exim4-daemon-heavy.
$ apt list --installed | grep exim4
WARNING: apt does not have a stable CLI interface. Use with caution in
scripts.
exim4-base/mantic-updates,mantic-security,now 4.96-17ubuntu2.2 amd64
[installed,automatic]
exim4-config/mantic-updates,mantic-security,now
Hi Dominic,
Thanks for the additional information.
Are you using exim4-daemon-heavy or exim4-daemon-light? In case you are
using the light version, could you try it with the heavy one as well and
report it back here?
--
You received this bug notification because you are a member of Ubuntu
Also: `update-exim4.conf` and restart exim before sending mail to
yourself.
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/2056372
Title:
Enabling SPF checks with CHECK_RCPT_SPF doesn't work
To
exim4.conf.template is completely unmodified from stock mantic.
Bug can be replicated by:
1. Installing mantic
2. Installing exim4 and spf-tools-perl
3. `dpkg-reconfigure exim4-config` and make it accept mail
4. Adding CHECK_RCPT_SPF = true to /etc/exim4/exim4.conf.localmacros
5. Sending
Could you provide your config file? Also state if you applied any
customization in your set up? Those things would be useful to reproduce
what you described locally.
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
Hi Mitchell,
I am setting CHECK_RCPT_SPF = true in /etc/exim4/exim4.conf.localmacros
where local macros are typically set.
I have run `update-exim4.conf` and `systemctl restart exim4`.
Then I send myself an email from an outlook.com account, which has SPF
enabled, and the headers report:
Hi Dominic,
Thanks for taking the time to submit this bug report and make Ubuntu
better!
Where are you setting the variable CHECK_RCPT_SPF = true ?
Doing a quick google search I found[0] which looks like it may be
useful. It says to do the following -
1) Add `CHECK_RCPT_SPF = true` to the top
Note: this bug relates to inbound IPv4 addresses. IPv6 addresses are
affected by a separate bug: #2056443
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/2056372
Title:
Enabling SPF checks with
49 matches
Mail list logo
