Forwarding mail without breaking SPF?

[Marek Kozlowski-2]

:-)

Some users forward their incoming mail to some external mail servers.
Unfortunately AFAIK with no action taken it may result in breaking the
SPF. The solution for this problem I know is rewriting addresses with
SRS (postsrsd). Unfortunately postsrsd uses the same settings as
canonicals do which in my case is inadvisable because I want canonicals
to operate independently of SRS. A few days ago I sent a post regarding
this problem.

Unfortunately I haven't received any answer. Using canonicals as well as
mail forwarding seem quite common so no answer may suggest that postfix
users don't use postsrsd for address rewriting. Moreover I can't find
any reference to SRS on the postfix webpage. The conclusion that comes
out is postfix provides some other mechanisms for avoiding violating SPF
on forward I'm unaware.

OK. I do not insist on postsrsd. I'd really appreciate any suggestion:
what can I use instaed of it - what do you recommend?

Best regards,
Marek

[Benny Pedersen-2]

Den 26-11-2019 kl. 17:59 skrev Marek Kozlowski:

> OK. I do not insist on postsrsd. I'd really appreciate any suggestion:
> what can I use instaed of it - what do you recommend?

no one uses spf anymore since it breaks mailling lists very badly ?,
postfix maillist have not even spf helo pass :)

spf works only on direkt mail, not mailling lists since envelope sender
changes on maillists

so if you add spf to your domain it would not make bad things ever

dmarc is another storry not to try

[Wietse Venema]

Marek Kozlowski:
> :-)
>
> Some users forward their incoming mail to some external mail servers.
> Unfortunately AFAIK with no action taken it may result in breaking the
> SPF. The solution for this problem I know is rewriting addresses with
> SRS (postsrsd). Unfortunately postsrsd uses the same settings as
> canonicals do which in my case is inadvisable because I want canonicals
> to operate independently of SRS. A few days ago I sent a post regarding
> this problem.

What is the problem? Perhaps you are unaware that Postfix canonical
mapping is recursive, and that it can apply multiple mappings.

        Wietse

[Marek Kozlowski-2]

:-)

>> Some users forward their incoming mail to some external mail servers.
>> Unfortunately AFAIK with no action taken it may result in breaking the
>> SPF. The solution for this problem I know is rewriting addresses with
>> SRS (postsrsd). Unfortunately postsrsd uses the same settings as
>> canonicals do which in my case is inadvisable because I want canonicals
>> to operate independently of SRS. A few days ago I sent a post regarding
>> this problem.
>
> What is the problem? Perhaps you are unaware that Postfix canonical
> mapping is recursive, and that it can apply multiple mappings.

I've wrote it on 20.11. Again:

The recommended configuration of postsrsd is quite simple and as follows
(main.cf):

sender_canonical_maps = tcp:localhost:10001
sender_canonical_classes = envelope_sender
recipient_canonical_maps = tcp:localhost:10002
recipient_canonical_classes= envelope_recipient,header_recipient

which in my case is:

sender_canonical_maps = unionmap:{ldap:/etc/postfix/ldap-canonical.cf,
ldap:/etc/postfix/ldap-canonical2.cf, tcp:127.0.0.1:10001}
sender_canonical_classes = envelope_sender
recipient_canonical_maps = tcp:127.0.0.1:10002
recipient_canonical_classes = envelope_recipient, header_recipient

due to some necessary address rewriting based on some LDAP attributes
(postsrsd daemon works of 10001 and 10002 ports). For envelope addresses
as well as the `To:' field everything is fine. The problem concerns the
`From:' field:

For some reasons I'd need to do some rewriting of the `From:' field (or
`Reply-To:') based on some subtle LDAP queries' results. Of course I
don't want SRS to modify it. Unfortunately both: canonicals and SRS use
the same postfix configuration parameters:

sender_canonical_maps
sender_canonical_classes

so I have no idea how to turn on canonical and simultaneously disable
SRS for it. I'm wondering if I could do some canonical-like rewriting
and no SRS. Something like:

sender_canonical_maps = unionmap:{ldap:/etc/postfix/ldap-canonical.cf,
ldap:/etc/postfix/ldap-canonical2.cf}

for the `From:' field and:

sender_canonical_maps = unionmap:{ldap:/etc/postfix/ldap-canonical.cf,
ldap:/etc/postfix/ldap-canonical2.cf, tcp:127.0.0.1:10001}

for envelope sender (`Return-Path').

Best regards,
Marek

[Wietse Venema]

Marek Kozlowski:

> :-)
>
> >> Some users forward their incoming mail to some external mail servers.
> >> Unfortunately AFAIK with no action taken it may result in breaking the
> >> SPF. The solution for this problem I know is rewriting addresses with
> >> SRS (postsrsd). Unfortunately postsrsd uses the same settings as
> >> canonicals do which in my case is inadvisable because I want canonicals
> >> to operate independently of SRS. A few days ago I sent a post regarding
> >> this problem.
> >
> > What is the problem? Perhaps you are unaware that Postfix canonical
> > mapping is recursive, and that it can apply multiple mappings.
>
> I've wrote it on 20.11. Again:
>
> The recommended configuration of postsrsd is quite simple and as follows
> (main.cf):
>
> sender_canonical_maps = tcp:localhost:10001
> sender_canonical_classes = envelope_sender
> recipient_canonical_maps = tcp:localhost:10002
> recipient_canonical_classes= envelope_recipient,header_recipient
>
> which in my case is:
>
> sender_canonical_maps = unionmap:{ldap:/etc/postfix/ldap-canonical.cf,
> ldap:/etc/postfix/ldap-canonical2.cf, tcp:127.0.0.1:10001}

By design, unionmap can produce multiple results separated by comma.
That would be wrong.

Why not:

sender_canonical_maps = ldap:/etc/postfix/ldap-canonical.cf,
    ldap:/etc/postfix/ldap-canonical2.cf. tcp:127.0.0.1:10001

That produces one result, and it still ensures that each
mapping will be tried.

> sender_canonical_classes = envelope_sender
> recipient_canonical_maps = tcp:127.0.0.1:10002
> recipient_canonical_classes = envelope_recipient, header_recipient
>
> due to some necessary address rewriting based on some LDAP attributes
> (postsrsd daemon works of 10001 and 10002 ports). For envelope addresses
> as well as the `To:' field everything is fine. The problem concerns the
> `From:' field:

Looks like you need to use SRS to rewrite envelopes, and LDAP to
rewrite some headers.

Can you use smtp_generic_maps for the LDAP stuff?

        Wietse

[Marek Kozlowski-2]

:-)

>> sender_canonical_maps = unionmap:{ldap:/etc/postfix/ldap-canonical.cf,
>> ldap:/etc/postfix/ldap-canonical2.cf, tcp:127.0.0.1:10001}
>
> By design, unionmap can produce multiple results separated by comma.
> That would be wrong. >
> Why not:
>
> sender_canonical_maps = ldap:/etc/postfix/ldap-canonical.cf,
>      ldap:/etc/postfix/ldap-canonical2.cf. tcp:127.0.0.1:10001
>
> That produces one result, and it still ensures that each
> mapping will be tried.

A good question.
Honestly, there must have been some reason when I configured it a lot of
time ago.. I don't remember now ;-) Let me think a little bit and
refresh my memory ;-)) However, it has nothing to do with the question.

>> sender_canonical_classes = envelope_sender
>> recipient_canonical_maps = tcp:127.0.0.1:10002
>> recipient_canonical_classes = envelope_recipient, header_recipient
>>
>> due to some necessary address rewriting based on some LDAP attributes
>> (postsrsd daemon works of 10001 and 10002 ports). For envelope addresses
>> as well as the `To:' field everything is fine. The problem concerns the
>> `From:' field:
>
> Looks like you need to use SRS to rewrite envelopes, and LDAP to
> rewrite some headers.
>
> Can you use smtp_generic_maps for the LDAP stuff?

Well, AFAIK smtp_generic_maps works for outgoing mail only (when sending
mail to an external system).

We have a very strange configuration "in transition". There is a very
old server (postfix2) with no LDAP support and local accounts and its
users are being successively migrated to the new LDAP-based
infrastructure. Some are being server by the new one (let's say: 5000),
while some - the old one (~300). Moreover the new server serves the same
domain as the old one and one more. Moreover temporarily some mailing
lists are served by mailman, some by postfix - LDAP multivalued
attributes and smtpd_restriction_classes / check_sender_access for
control; some by the old server, some by the new one.

We're keeping the migration transparent to our users and external
senders; users' addresses don't change. They are unaware which server
serves them and which one - their recipients or lists. So we're using a
very complex re-mappings involving canonicals and virtuals based on LDAP.

In short: we need to rewrite addresses for both remote and local
deliveries and AFAIK canonicals are intended for this purpose..?

Best regards,
Marek

[Richard Damon]

On 11/26/19 2:07 PM, Benny Pedersen wrote:

> Den 26-11-2019 kl. 17:59 skrev Marek Kozlowski:
>
>> OK. I do not insist on postsrsd. I'd really appreciate any
>> suggestion: what can I use instaed of it - what do you recommend?
>
> no one uses spf anymore since it breaks mailling lists very badly ?,
> postfix maillist have not even spf helo pass :)
>
> spf works only on direkt mail, not mailling lists since envelope
> sender changes on maillists
>
> so if you add spf to your domain it would not make bad things ever
>
> dmarc is another storry not to try
>

SPF does NOT break from a properly configured mailinglist, as SPF
doesn't check just from, but can also use sender/envelope-from, which a
proper mailing-list should set to itself, so SPF will pass.

DMARC/SPF, which only validates to the From: header will break.

--
Richard Damon

[Wesley Peng-9]

Hello

on 2019/11/27 12:20, Richard Damon wrote:
> DMARC/SPF, which only validates to the From: header will break.

If the sender domain set up SPF to:

v=spf1 ip4:0.0.0.0/0 ~all

Will this pass through any SPF check?

regards.

[Matus UHLAR - fantomas]

>> Den 26-11-2019 kl. 17:59 skrev Marek Kozlowski:
>>> OK. I do not insist on postsrsd. I'd really appreciate any
>>> suggestion: what can I use instaed of it - what do you recommend?

>On 11/26/19 2:07 PM, Benny Pedersen wrote:
>> no one uses spf anymore

incorrect.

>> since it breaks mailling lists very badly ?,
>> postfix maillist have not even spf helo pass :)

They don't have SPF helo fail. "No SPF" is correct result.

>> spf works only on direkt mail, not mailling lists since envelope
>> sender changes on maillists

spf can work on any mail, even mailing list.

>> so if you add spf to your domain it would not make bad things ever
>>
>> dmarc is another storry not to try

On 26.11.19 23:20, Richard Damon wrote:
>SPF does NOT break from a properly configured mailinglist, as SPF
>doesn't check just from, but can also use sender/envelope-from,

incorrect. SPF is only supposed to check envelope from:, not any headers.


Checking header From: was stupid microsoft attempt for spf/2 that failed.

Once again, SPF does not apply to mail headers.

--
Matus UHLAR - fantomas, [hidden email] ; http://www.fantomas.sk/
Warning: I wish NOT to receive e-mail advertising to this address.
Varovanie: na tuto adresu chcem NEDOSTAVAT akukolvek reklamnu postu.
LSD will make your ECS screen display 16.7 million colors

[Ralph Seichter-2]

* Matus UHLAR:

> Once again, SPF does not apply to mail headers.

Matus, I feel your frustration.

I mentioned RFC 7208 before in this thread. If only people would read
section 2.2 (https://tools.ietf.org/html/rfc7208#section-2.2) ff., to
understand how SPF authorization works and where in the STMP transaction
it occurs.

-Ralph

[Scott Kitterman-4]

On Wednesday, November 27, 2019 2:03:40 PM EST Ralph Seichter wrote:
> * Matus UHLAR:
> > Once again, SPF does not apply to mail headers.
>
> Matus, I feel your frustration.
>
> I mentioned RFC 7208 before in this thread. If only people would read
> section 2.2 (https://tools.ietf.org/html/rfc7208#section-2.2) ff., to
> understand how SPF authorization works and where in the STMP transaction
> it occurs.

And, amazing as it may seem to some people, we weren't blind to these kind of
architectural issues when we wrote RFC 7208.  There's even an appendix [1]
devoted to discussion of alternatives available to ameliorate such issues.

This was argued approximately to death in 2004/2005 when SPF was first
standardized and repeatedly since then.  I think it's been at least a good
decade since anyone had any new ideas on the topic.

There is a mailing list devoted to giving people help with SPF [2].  Asking
SPF specific questions is really more on topic there.

Scott K

[1] https://tools.ietf.org/html/rfc7208#appendix-D
[2] https://spf.topicbox.com/groups/spf-help