1. Forum
  2. Usenet
  3. COMP.MAIL.SENDMAIL

  • .forward woes with SPF

    From Grant Taylor@21:1/5 to All on Sun Dec 19 18:00:46 2021
    Hi,

    I was wondering if anyone had any guidance / pro tips on how to deal
    with SPF related issues when using .forward files.

    I have email coming into a system from addresses that are protected with
    SPF (-all). The inbound email makes it to the mailbox that is the
    original recipient. The problem arises when I add .forward to the mix.
    The new .forward recipient is hosted by a system that honors strict SPF
    checks, and as such rejects the forwarded message because it violates
    the original sender's domain's strict SPF (-all).

    I /think/ that I want to utilize some form of masquerading on the
    intermediate system that hosts the original recipient. But I'm not sure
    /if/ masquerading is what I want, much less how to configure it to
    masquerade for any and all from addresses. (I'd rather not need to
    explicitly list original source domains in a game of whack-a-mole.)

    I feel like I would describe this as SNAT on the intermediate system if
    I were to borrow IP networking terms.

    Does anyone have any guidance / pro tips?



    --
    Grant. . . .
    unix || die

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From John Levine@21:1/5 to All on Mon Dec 20 03:00:39 2021
    According to Grant Taylor <[email protected]>:
    Telling myself to poll a different mailbox is ... let's go with a >non-starter.

    Oh, if you're forwarding to yourself that makes it a lot easier.

    Now you know why we all ignore SPF -all except for the edge case
    of an SPF record that only says -all for a domain that sends no
    mail.

    R's,
    John
    --
    Regards,
    John Levine, [email protected], Primary Perpetrator of "The Internet for Dummies",
    Please consider the environment before reading this e-mail. https://jl.ly

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From John Levine@21:1/5 to [email protected] on Mon Dec 20 02:17:13 2021
    It appears that Grant Taylor <[email protected]> said:
    I was wondering if anyone had any guidance / pro tips on how to deal
    with SPF related issues when using .forward files.

    I have email coming into a system from addresses that are protected with
    SPF (-all).

    They are telling you not to forward their mail. So don't.

    I realize their advice may be ill-considered or ignorant, but so be it.

    FWIW I have largely given up on forwarding and tell my users who want
    to get their mail somewhere else to set up their other provider to
    poll their mailbox here.

    I realize there is a thing called SRS which is supposed to fix the SPF forwarding problem, but I haven't found it very useful in practice, since
    it turn SPF fails into DMARC fails.

    R's,
    John
    --
    Regards,
    John Levine, [email protected], Primary Perpetrator of "The Internet for Dummies",
    Please consider the environment before reading this e-mail. https://jl.ly

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Grant Taylor@21:1/5 to John Levine on Sun Dec 19 19:42:24 2021
    On 12/19/21 7:17 PM, John Levine wrote:
    They are telling you not to forward their mail. So don't.

    The thing that I left out, because I didn't think it mattered, is that
    I'm all three parties in this situation, original source, original
    destination, and forwarded destination. So ... yes, but no.

    I realize their advice may be ill-considered or ignorant, but so be it.

    Chuckle.

    FWIW I have largely given up on forwarding and tell my users who want
    to get their mail somewhere else to set up their other provider to
    poll their mailbox here.

    Telling myself to poll a different mailbox is ... let's go with a
    non-starter.

    I realize there is a thing called SRS which is supposed to fix the SPF forwarding problem, but I haven't found it very useful in practice,
    since it turn SPF fails into DMARC fails.

    I've actually got SRS working with Sendmail and it doesn't make any real difference in this case.

    More details on the mail flow are as follows:

    1) [email protected]e sends a message to [email protected]e.
    2) [email protected]e .forwards to [email protected]e.

    [email protected]e could just as easily be <something>@gmail.com as
    both domain1.example and gmail.com have similar (but not identicle) restrictions.

    domain1.example and domain3.example are hosted on the same host. domain2.example uses the same host as the inbound MX from the world and mailertable rotues to the internal host.

    So ...

    1) Something ([email protected]e / <something>@gmail.com) sends an
    email to [email protected]e which relays through the public host on
    it's way to the internal host.
    2) The internal host receives the email from something to [email protected]e.
    3) The internal host .forwards the message to [email protected]e.
    4) The public host rejects the message from something
    ([email protected]e / <something>@gmail.com) because the message
    runs afoul of SPF (-all).

    A little more background: I have many systems that .forward messages
    from them to special addresses on my main mail server. E.g <REDACTED>@domain2.example .forwards to
    domain2@<REDACTED>.domain1.example. This means that systems I have
    configured .forward messages from cron and the likes to my central account.

    I just started testing something wherein email from the public Internet
    was going into my address on one of my hosts, where it dutifully
    forwarded to the host's sub-domain address on the main mail server.
    Except ... SPF.

    Seeing as how I have full control of the leafe systems in question which
    are .forwarding to my central account, I am quite content if they
    masquerade everything that leaves the system to appear to be from me /
    my address on said leafe system.

    I could do what I want by enhancing .forward to pipe into a program that
    would turn the message into an RFC 822 attachment to a new email. But
    that seems ... overkill.


    --
    Grant. . . .
    unix || die

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Grant Taylor@21:1/5 to John Levine on Sun Dec 19 20:25:19 2021
    On 12/19/21 8:00 PM, John Levine wrote:
    Oh, if you're forwarding to yourself that makes it a lot easier.

    Does it? Does it fundamentally alter the situation? I don't think it does.

    Now you know why we all ignore SPF -all except for the edge case
    of an SPF record that only says -all for a domain that sends no
    mail.

    You say /now/ as if I didn't grok this before. I /did/ grok it.

    Note: When I asked about masquerading the (envelope and / or header)
    sender, I was conveying that I'm exploring /how/ to solve the end to end delivery conundrum /within/ the established constraints.

    I say "conundrum" as opposed to "problem" because I believe that things
    are working the way that they are supposed to. I have zero desire to
    alter my SPF (-all) stance. I'd much rather alter the message so that
    it no longer ran afoul of SPF. Hence masquerading ~> altering the from
    address to be the intermediate account.

    I /feel/ like and /want/ /to/ /believe/ -- thank you Fox Mulder -- that
    there is a way to achieve my goal.



    --
    Grant. . . .
    unix || die

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Claus =?iso-8859-1?Q?A=DFmann?= @21:1/5 to Grant Taylor on Mon Dec 20 00:55:45 2021
    Grant Taylor wrote:

    The thing that I left out, because I didn't think it mattered, is that
    I'm all three parties in this situation, original source, original destination, and forwarded destination. So ... yes, but no.

    So why don't you disable SPF tests when mail is coming from
    one of your own hosts?

    Maybe you should reconsider in which situations SPF might
    actually be "useful".

    --
    Note: please read the netiquette before posting. I will almost never
    reply to top-postings which include a full copy of the previous
    article(s) at the end because it's annoying, shows that the poster
    is too lazy to trim his article, and it's wasting the time of all readers.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Grant Taylor@21:1/5 to All on Sun Dec 19 23:25:44 2021
    On 12/19/21 10:55 PM, Claus Aßmann wrote:
    So why don't you disable SPF tests when mail is coming from
    one of your own hosts?

    Because $REASONS. Let's agree to disagree and move past is SPF a Good
    Thing™ or a Bad Thing™.

    Maybe you should reconsider in which situations SPF might actually be "useful".

    I think that SPF is doing /exactly/ what it's supposed to based on what
    I've asked it to do. Said another way, SPF is doing what it is
    configured and intended to do in this situation.



    --
    Grant. . . .
    unix || die

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Andrzej Adam Filip@21:1/5 to Grant Taylor on Mon Dec 20 08:00:08 2021
    Grant Taylor <[email protected]> wrote:
    I was wondering if anyone had any guidance / pro tips on how to deal
    with SPF related issues when using .forward files.

    I have email coming into a system from addresses that are protected
    with SPF (-all). The inbound email makes it to the mailbox that is
    the original recipient. The problem arises when I add .forward to the
    mix. The new .forward recipient is hosted by a system that honors
    strict SPF checks, and as such rejects the forwarded message because
    it violates the original sender's domain's strict SPF (-all).

    I /think/ that I want to utilize some form of masquerading on the intermediate system that hosts the original recipient. But I'm not
    sure /if/ masquerading is what I want, much less how to configure it
    to masquerade for any and all from addresses. (I'd rather not need to explicitly list original source domains in a game of whack-a-mole.)

    I feel like I would describe this as SNAT on the intermediate system
    if I were to borrow IP networking terms.

    Does anyone have any guidance / pro tips?

    My start suggestion (from a small Linux system perspective):
    Use per OS account procmail script for forwarding.
    It will change envelope sender address to local one.

    If for some reasons it does not fit your need state why.

    --
    [Andrew] Andrzej A. Filip

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Grant Taylor@21:1/5 to Andrzej Adam Filip on Mon Dec 20 10:44:04 2021
    On 12/20/21 1:00 AM, Andrzej Adam Filip wrote:
    My start suggestion (from a small Linux system perspective): Use per
    OS account procmail script for forwarding. It will change envelope
    sender address to local one.

    Calling some sort of program via .forward or procmail seems to be
    floating to the surface.

    If for some reasons it does not fit your need state why.

    I've not tried it yet. The few but I don't wanna things that come to
    mind are:

    - It's per user and doesn't address multiple users on the system.
    - Additional dependencies - procmail isn't installed on all the
    systems I would use this on.
    - It leaves me wondering if this is strictly necessary. -- I've not
    yet found something I wanted to do that couldn't be handled by Sendmail
    itself. This makes me question if there truly is no Sendmail solution
    or if I simply haven't found it yet. With the latter being more likely.

    If I'm going to create a forwarding agent, I'm likely going to do it
    once and have it do multiple things:
    - Attach the incoming message as an RFC 822 attachment.
    - Use the Auto-Submitted: header.
    - Make sure to do loop avoidance.
    - Log what it does.
    - Save received messages somewhere. -- Should probably purge things
    after a while too.
    - Use SMTP Authentication to send directly to my own server.
    - Use STARTTLS.

    This is quickly turning into quite a bit more than just change $SETTINGS
    to do what you want.

    But the mail forwarding agent does comply with my belief that email
    addresses are terminal endpoints; starting and ending, for messages. A
    la. mailing lists receive a message and generate a new one substantively
    based on the incoming message.



    --
    Grant. . . .
    unix || die

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From John Levine@21:1/5 to [email protected] on Mon Dec 20 20:42:37 2021
    It appears that Grant Taylor <[email protected]> said:
    I say "conundrum" as opposed to "problem" because I believe that things
    are working the way that they are supposed to. I have zero desire to
    alter my SPF (-all) stance. I'd much rather alter the message so that
    it no longer ran afoul of SPF. Hence masquerading ~> altering the from >address to be the intermediate account.

    That's SRS. It seems to me to be swatting a fly with a chain saw
    but chacun a son gout.

    http://www.open-spf.org/srs/

    --
    Regards,
    John Levine, [email protected], Primary Perpetrator of "The Internet for Dummies",
    Please consider the environment before reading this e-mail. https://jl.ly

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)