new feature: sieve forward plugin

Robert Schetterer rs at sys4.de
Mon Sep 26 14:20:27 UTC 2022


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 "shit at gmail.com";
> }
> 
>> 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



More information about the dovecot mailing list