Kitz ADSL Broadband Information
adsl spacer  
Support this site
Home Broadband ISPs Tech Routers Wiki Forum
 
     
   Compare ISP   Rate your ISP
   Glossary   Glossary
 
Please login or register.

Login with username, password and session length
Advanced search  

News:

Pages: 1 [2]

Author Topic: Email redirection  (Read 5979 times)

sevenlayermuddle

  • Helpful
  • Addicted Kitizen
  • *
  • Posts: 5369
Re: Email redirection
« Reply #15 on: May 02, 2020, 11:36:45 PM »

Thanks John.

I’m still not entirely clear.  I’d not expect a forwarding server to modify sender in the header, as the final recipient expects to see the original sender’s address?   That is why I thought final destination would refer back to original sender’s SPF rule.

But no worries, happy to leave it at that, and that it’s my failure to understand.  Thanks for taking time to explain things. :)

Logged

d2d4j

  • Kitizen
  • ****
  • Posts: 1103
Re: Email redirection
« Reply #16 on: May 03, 2020, 08:13:58 AM »

Hi

Many thanks

I think it’s important to note any email been sent or forwarded must include the sender details within the headers (covered by RFC rules). This cannot be overridden by email users so a traceable header is given

However, the email remains intact in every way and the recipient who finally received the email would be able to click reply and the correct reply address is used.

The recipient may not know or be interested in which mail servers were used to send.

If you would like to see this, O365 gives a good header for email been forwarded to different email servers for filtering and then final transmission to recipient. So just look at any email received from a domain using O365 you may receive

It is also important to note that these headers can be removed or altered at sending server but at the receiving server end, you cannot alter or change them from the sender server (so you cannot hide your sender details) and these headers are also included in the header of the recipient email

So in my example used above in previous post, it is the sender mail url used and checked along with PTR which both should match and pass.

As I said, there is a lot more but hopefully this should help to answer your question

It is also worth pointing out that email is not a new concept and your question and many more have been asked/resolved many years ago

Many thanks

John
Logged

d2d4j

  • Kitizen
  • ****
  • Posts: 1103
Re: Email redirection
« Reply #17 on: May 03, 2020, 09:34:36 AM »

Hi

To show you what I mean please see below (note this is not an forwarded email but shows the number of mail servers used by Exchange before final delivery - so in this example 4)

Many thanks

John

Received: from EUR04-VI1-obe.outbound.protection.outlook.com (mail-eopbgr80105.outbound.protection.outlook.com [40.107.8.105]) by nnnnn.receiving-server with SMTP;
   Mon, 13 Apr 2020 16:31:30 +0100

Received: from DB8PR03MB6041.eurprd03.prod.outlook.com (2603:10a6:10:ef::13)
 by DB8PR03MB6155.eurprd03.prod.outlook.com (2603:10a6:10:141::15) with
 Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2900.15; Mon, 13 Apr
 2020 15:31:10 +0000

Received: from DB8PR03MB6041.eurprd03.prod.outlook.com
 ([fe80::593b:562:8e01:c80e]) by DB8PR03MB6041.eurprd03.prod.outlook.com
 ([fe80::593b:562:8e01:c80e%7]) with mapi id 15.20.2900.028; Mon, 13 Apr 2020
 15:31:10 +0000

originator details removed/not shown to protect identities (2)
Logged

sevenlayermuddle

  • Helpful
  • Addicted Kitizen
  • *
  • Posts: 5369
Re: Email redirection
« Reply #18 on: May 03, 2020, 12:00:58 PM »

A few observations, John...

From Wikipedia, SPF article...
https://en.wikipedia.org/wiki/Sender_Policy_Framework
Quote
FAIL and forwarding[edit]
SPF breaks plain message forwarding. When a domain publishes an SPF FAIL policy, legitimate messages sent to receivers forwarding their mail to third parties may be rejected and/or bounced if all of the following occur:

The forwarder does not rewrite the Return-Path, unlike mailing lists.
The next hop does not whitelist the forwarder.
This hop checks SPF.

This is a necessary and obvious feature of SPF – checks behind the "border" MTA (MX) of the receiver cannot work directly.
Publishers of SPF FAIL policies must accept the risk of their legitimate emails being rejected or bounced. They should test (e.g., with a SOFTFAIL policy) until they are satisfied with the results. See below for a list of alternatives to plain message forwarding.

I'm probably asking for trouble here, paraphrasing the issue myself I've already linked to what is probably a much better article.  But I'll risk it....

...When a server domain passes mail between servers within its own domain, it would either not bother checking SPF, or it would whitelist its own servers, that explains why the various outlook servers shuffled things around before delivery.  The problem arises when mail arises at a node that does check SPF, and finds that the sending IP address is not authorised to generate mail on behalf of the sender's domain.

As an example, since I use Google Apps, and my own DNS SPF records authorise various Google's IP addresses to generate mail from my domain, with a 'soft fail' for unauthorised IPs.  This works perfectly of course, for mail sent using IMAP upload to Google for my domain.    But I also occasionally generate email directly to my own addresses, from my own home within Linux shell scripts, in which case the originating IP is my own ISP-assigned IP address.  These messages correctly fail SPF and are, by default, delivered to my spam folder.  I could add my own IP as an SPF authorised sender but I have not done so, it's an incentive to check my spam once in a while.

When I refer to 'forwarding' I am not talking about opening a mail client and forwarding a message.  That would work, because the recipient would see a message forwarded by 7lm, ie it was sent by 7lm, and would find that came from Google, and so it passes SPF.

The forwarding scenario that I don't like is...   Some registrars/hosts that I have used in the past offer a transparent forwarding service, whereby mail arriving at the domain is forwarded to some other address, the intention being that mail appears exactly as if it had been addressed to that new address in the first place.  This is, effectively, sender 'spoofing', which is what, by my understanding,  SPF is intended to stop.    If the final receiving server then performs an SPF check, it will think that mail was sent by the IP of the forwarding host.  We can't assume that the forwarding host's IP was authorised by the sender and so, if the sender has configured his DNS for SPF, SPF will fail.
Logged

d2d4j

  • Kitizen
  • ****
  • Posts: 1103
Re: Email redirection
« Reply #19 on: May 03, 2020, 01:16:14 PM »

Hi

Sorry that’s a long post...

The example I posted was edited for easy viewing of the servers. All other information was not shown - apologies I thought that was evident to all. FYI exchange checks spf as do all our mail platforms

I think your overthinking spf, which upon first introduction was easily spoofed and has never really been widely adopted by all domains. Look how many do not have any spf records.

I could send an email pretending to be from a n other and genuinely have spf pass, even if your spf is set to hardfail and would be delivered. This without any special software or changes to any mail servers... it takes a few mouse clicks

So that’s the reason why other more reliable checks are undertaken  and spf check only forms a small proportion of checks

Reputation checks are now been more relied upon at mail server level and you need to send a certain amount of email daily in order to be scored. If your not scored you are classed poor or very poor and Mail is rejected in full

Whitelisting is legal and forms part of smarthost, as is server to server on your own backbone

I’ll leave it at that

Many thanks

John
Logged

sevenlayermuddle

  • Helpful
  • Addicted Kitizen
  • *
  • Posts: 5369
Re: Email redirection
« Reply #20 on: May 03, 2020, 02:32:56 PM »

Logged
Pages: 1 [2]