Re: sender rewrining advice

Liste des GroupesRevenir à cm sendmail 
Sujet : Re: sender rewrining advice
De : gtaylor (at) *nospam* tnetconsulting.net (Grant Taylor)
Groupes : comp.mail.sendmail
Date : 20. Mar 2024, 03:56:52
Autres entêtes
Organisation : TNet Consulting
Message-ID : <utdfp4$fs6$1@tncsrv09.home.tnetconsulting.net>
References : 1 2 3
User-Agent : Mozilla Thunderbird
On 3/18/24 15:25, none wrote:
yes mailertable, but no fall back at all.
ACK

mailertable, only a few entries in LDAP routing
Please elaborate on which you're using when and why.
My experience and understanding is that mailertable routes at the domain level while LDAP routing can route at the address level.

I am not really doing anything yet. I have some people on LOCAL using forwarding, which are starting to generate spf bounces.
ACK

But in the near future I would like to offer an email address that is forwarded, that I configure and not some users turning it off/on.
Okay.
N.B. IMHO there is very little difference between how the forwarding is done when it comes to SRS.

I tested a bit with ldap routing. I would be able to forward remotely via MailLocalAdress and MailRoutingAddress
Nomenclature becomes extremely important and we quickly get into minutia.

test@gmail.com -> test@me.com received at MX -> test@guerrillamail.com
Is me.com one of your addresses or Apple's iCloud?

I think it would be nicer if I could skip processing on LOCAL.
You should be able to forward directly on MX without needing to loop through LOCAL.

There will be email addresses on this @me.com that are just delivered to regular mailboxes on LOCAL.
It looks like you are using @me.com as a reference to your own domain, not Apple's iCloud me.com.
Which system thinks that it is responsible for -- I'm going to say -- @example.com?  MX or LOCAL?
If you are using LDAP routing, you can have MX think that @example.com is local to it.  --  I think, based on my understanding.
If you aren't using LDAP routing then you would probably need to make MX relay @example.com over to LOCAL and LOCAL would think that @example.com is local to it.

I have limited experience with smart hosts. Only used in situations where all traffic is forwarded.
ACK

I think I have fair amount of local deliveries also on OUTGOING. What is the problem with local delivery and SRS?
SRS doesn't interfere with delivery.  SRS alters the SMTP envelope /from/ address.  SRS could happen at each SMTP hop along the way and it shouldn't adversely impact delivery.

I thought the SRS milters could be given something like ip ranges to determine what is local and not?
I don't know how an SRS milter would work.  As such I can't speak to how they do and don't operate.
I'm not using a milter to do SRS.  I've got SRS hooked into Sendmail as part of one of it's rule sets.

Yes that would be my 2nd point of attention. Handling these user forwards correctly. But I thought focussing on just forwarding at the MX would be easier for now.
The way that I'm using SRS, Sendmail looks to see if the recipient email domain is local to itself or if it's to be sent somewhere off box.  If the email is to be sent somewhere off box, then SRS is used.  Thus email from LOCAL (via .forward files thereon) going anywhere not on LOCAL (assuming SRS is done on LOCAL) will be rewritten.
If you would, please change the example names that you have used to something that doesn't collide with other functions; e.g.
  - MX is a function, not a host name
  - LOCAL is a definition for addresses, much like loopback / 127.0.0.1 in IPv4
  - @me.com is an often used domain name that is registered to Apple for their iCloud.
I think that clearer names / identifiers would help this discussion.
Also, please provide the name(s) that Sendmail things are local to each system.  Feel free to redact part of them if you want to, but something like a.example is on ${HOST_PREVIOUSLY_CALLED_MX}, b.example is local to ${HOST_PREVIOUSLY_CALLED_LOCAL}, and c.example is local to ${HOST_PREVIOUSLY_CALLED_OUTGOING}.  I think these (place holder) names are going to quickly become extremely important.
--
Grant. . . .

Date Sujet#  Auteur
17 Mar 24 * sender rewrining advice33none
17 Mar 24 +* Re: sender rewrining advice30Grant Taylor
18 Mar 24 i`* Re: sender rewrining advice29none
20 Mar 24 i `* Re: sender rewrining advice28Grant Taylor
20 Mar 24 i  `* Re: sender rewrining advice27none
21 Mar 24 i   `* Re: sender rewrining advice26Grant Taylor
21 Mar 24 i    `* Re: sender rewrining advice25none
23 Mar 24 i     `* Re: sender rewrining advice24Grant Taylor
23 Mar 24 i      +* Re: sender rewrining advice19Grant Taylor
23 Mar 24 i      i+* Re: sender rewrining advice7Grant Taylor
23 Mar 24 i      ii`* Re: sender rewrining advice6Grant Taylor
23 Mar 24 i      ii `* Re: sender rewrining advice5none
23 Mar 24 i      ii  `* Re: sender rewrining advice4Grant Taylor
23 Mar 24 i      ii   `* Re: sender rewrining advice3Grant Taylor
24 Mar 24 i      ii    `* Re: sender rewrining advice2none
24 Mar 24 i      ii     `- Re: sender rewrining advice1Grant Taylor
23 Mar 24 i      i+* Re: sender rewrining advice2none
23 Mar 24 i      ii`- Re: sender rewrining advice1Grant Taylor
23 Mar 24 i      i+* Re: sender rewrining advice4none
23 Mar 24 i      ii`* Re: sender rewrining advice3Grant Taylor
24 Mar 24 i      ii `* Re: sender rewrining advice2none
24 Mar 24 i      ii  `- Re: sender rewrining advice1Grant Taylor
24 Mar 24 i      i+* Re: sender rewrining advice2none
24 Mar 24 i      ii`- Re: sender rewrining advice1Grant Taylor
24 Mar 24 i      i`* Re: sender rewrining advice3none
25 Mar 24 i      i +- Re: sender rewrining advice1Grant Taylor
25 Mar 24 i      i `- Re: sender rewrining advice1Grant Taylor
23 Mar 24 i      +* Re: sender rewrining advice2none
23 Mar 24 i      i`- Re: sender rewrining advice1Grant Taylor
23 Mar 24 i      `* Re: sender rewrining advice2none
23 Mar 24 i       `- Re: sender rewrining advice1Grant Taylor
10 Apr 24 `* Re: sender rewrining advice2none
18 Apr 24  `- Re: sender rewrining advice1Grant Taylor

Haut de la page

Les messages affichés proviennent d'usenet.

NewsPortal