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-...
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/...
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 paul@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_...