Am 26.09.2022 um 15:19 schrieb Marc:
Hi Paul,
I appreciate the huge response! :)
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.
But this creates a dependency between your dovecot mail server and your
outgoing. You should keep things simple.
#Postgres Stuff
I am using ldap ;)
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.
Yes always. I do not see anything that distinguishes between senders that have
or have not set spf. It is still nice to receive the forwarded message
unchanged (think of internal delivery)
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?
I have no idea, but this code forwards, so it should be possible to change the
envelope here at this stage.
# rule:[Forward]
if false # true
{
redirect :copy "[email protected]";
}
remapping the address through postfix would be the better approach.
No, because postfix needs to know, and you create complicated relationships
between outgoing mail servers and your mail server.
It would not surprise me if your solution is also using much more resources,
because your solution constantly has to verify. Less cpu cycles is better for
the environment. ;)
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?
No, not really relevant.
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.
I see a manual about "Outbound delivery pools" no explanaition of why spf
should not have '-all'
Apparently google is now also using unverified (or insecure) servers
setup the same way.
why i have no idea?
The only reason for using ~all, is because they do not know what servers are
sending outgoing email. Afaik this is just a statement of being incompetent.
Google does not give a fuck if others need to clean up their mess.
Microsoft replied with the ticket after 3 months of messing around that
they would not fix their spf record.
Microsoft and Google are probably the companies you do 'business' with that have broken
more laws than anyone else you know. Recently I have seen that Bill Gates is proud of his
slogan "Why you should hire lazy people". Which undoubtedly is the cause of
much of the shit I have with windows/exchange/outlook.
So forgive me if I do not really take Microsoft or Google as an example nor
standard.
i wrote something about this issue
years ago
https://blog.sys4.de/email-forward-mit-sieve-ohne-spf-dmarc-und-dkim-konflikte-de.html
--
[*] sys4 AG
https://sys4.de, +49 (89) 30 90 46 64
Schleißheimer Straße 26/MG,80333 München
Sitz der Gesellschaft: München, Amtsgericht München: HRB 199263
Vorstand: Patrick Ben Koetter, Marc Schiffbauer, Wolfgang Stief
Aufsichtsratsvorsitzender: Florian Kirstein
