Ok this in itself is a issue however forwards should be fully received
by the server and then resent to get around this issue.
I use the mapping feature & the database to handle forwards in postfix
which appears to work without any issues bypassing sieve.
#Postgres Stuff
mydestination = pgsql:/usr/home/postfix/config/pgsql-mydestination.cf
#virtual_maps=pgsql:/usr/home/postfix/config/pgsql-virtual.cf
alias_maps=pgsql:/usr/home/postfix/config/pgsql-aliases.cf
#sender_canonical_maps = pgsql:/usr/home/postfix/config/pgsql-canonical.cf
with
# cat pgsql-mydestination.cf
# /etc/postfix/pgsql-mydestination.cf
#####################################
# pgsql config file for local domain (like sendmail's sendmail.cw)
# lookups on postfix
# comments are ok.
#
# the user name and password to log into the pgsql server
hosts = pg.scom.ca:5433
user =
password =
# the database name on the servers
dbname = scom_billing
# the table name
table = email_users
#
select_field = domain
where_field = domain
and
# cat /usr/home/postfix/config/pgsql-aliases.cf
# **** pgsql-virtual.cf ***
#
# pgsql config file for alias lookups on postfix
# comments are ok.
#
# the user name and password to log into the pgsql server
hosts = pg.scom.ca:5433
user =
password =
# the database name on the servers
dbname = scom_billing
# the table name
table = email_users
#
#Select source email address alias (ie sales@ etc aliases )
where_field = source
#Select destination email account address (final delivery)
select_field = destination
#Account Status (1=good)
additional_conditions = and status = '1'
So when using the above postfix receives it, remaps it and resends the
email as its own thus fixing any spf issues along the way as it is sent
by the local server.
I understand that forwarding in a sieve script might over ride this and
cause an spf failure, in that case (and i have not tried) then the sieve
script should somehow deliver local and then resend?
remapping the address through postfix would be the better approach.
this would mark the email as coming from the local sending server and
the spf record sent down the line would reflect that.
spf verification would have already been verified by incoming postfix so
you are not passing along something that got rejected in the first place?
(The comments below are a little off topic but not really - spf issues
are starting to become more of an issue as of late, it seems upstream
providers are more interested in collecting customer data then just
simply processing it and moving it along.)
I recently went through this with microsoft outlook 365
please refer to microsoft [Case #:32804718] - Ticket 32800372 / 32795526
spf records :
they refered me to a few links
https://docs.microsoft.com/en-us/microsoft-365/troubleshoot/antispam/sender-rewriting-scheme
sender-rewriting-scheme (which can not be turned off by microsoft)
basically takes the from address of the origional email and resets it to
the account email address thus when forwarded onwards the email only
see's the microsft email address, the origional is dropped and does not
even get passed in the headers.
&
https://docs.microsoft.com/en-us/microsoft-365/security/office-365-security/high-risk-delivery-pool-for-outbound-messages?view=o365-worldwide
the above link was microsoft's explanation on why they refused to fix
their spf record.
when forwarding by a rule in microsoft (the only way to preserve the
senders address email), microsoft receives it and then reque's the email
through another server (in principal this is correct) but the forwarding
server is considered insecure because microsoft fails their own spf
record on purpose.
Apparently google is now also using unverified (or insecure) servers
setup the same way.
why i have no idea?
Microsoft replied with the ticket after 3 months of messing around that
they would not fix their spf record.
so basically microsoft was by design blocking their own outgoing server
with an spf fail.
Caption from microsoft ticket.
We know nothing will make this better but to fix things on our side as
you have said, but based on what we understood and what you have
submitted to us, we understand the IP addresses you have mentioned are
not listed Exchange Online's SPF record, however this is by design as we
do not publish addresses for all traffic coming from our servers. In
particular, traffic being relayed through Exchange Online may be treated
this way. In order to ensure that mail flow is secure and being
processed correctly, we recommend you use connectors when routing mail
between Exchange Online and any on premise or partner organizations.
With your permission, I am archiving the ticket # 32804718.
that being said when i did a dig on outlook
dig txt spf.protection.outlook.com
i got back
spf.protection.outlook.com. 600 IN TXT "v=spf1 ip4:40.92.0.0/15
ip4:40.107.0.0/16 ip4:52.100.0.0/14 ip4:104.47.0.0/17
ip6:2a01:111:f400::/48 ip6:2a01:111:f403::/49
ip6:2a01:111:f403:8000::/50 ip6:2a01:111:f403:c000::/51
ip6:2a01:111:f403:f000::/52 include:spfd.protection.outlook.com -all"
all microsoft had to do was change
ip4:40.92.0.0/15
to
ip4:40.92.0.0/14
and the offending microsoft servers would have passed
I was forced to whitelist this in my spf hoping this would not let
anything bad through.
I now have to track spf bounces daily from microsoft in case they change
something else upstream that messes up my customer.
Whats the point of spf if it does not get used correctly in the config
record?
Typical microsoft, however google & bell.ca (canadian isp) are having
similiar issues when a customer of mine sends an email to 6 different
people at the same time (just a normal email list nothing fancy),
bell.ca (for example) seems to have that destination forwarded to google
and is bouncing back as an spf error anyways (and this is on a normal send)
So in the case of bell.ca's customer forwarding his/her account to
google somewhere along the line the origional spf record (from my
server) is being passed along upstream and when bell.ca rewrites it with
their own something is getting scrambled and google thinks it is coming
from my origional server but because it is going through bell.ca and
forwarding they are obviously having the same problem as described here?
Happy Monday !!!
Thanks - paul
Paul Kudla
Scom.ca Internet Services <http://www.scom.ca>
004-1009 Byron Street South
Whitby, Ontario - Canada
L1N 4S3
Toronto 416.642.7266
Main 1.866.411.7266
Fax 1.888.892.7266
Email p...@scom.ca
On 9/26/2022 6:22 AM, Marc wrote:
As this page[1] describes a more often occurring problem of forwarding messages
from servers that are not included in the spf records. Maybe there should be a
plugin that offers this forward functionality. Something like
get the spf records of the sender
check if there is a -all
then apply the sender substitution.
https://doc.dovecot.org/configuration_manual/sieve/configuring_auto_forward_sender_address/
