[pfx] Re: Postfix sending to undefined (?)

2023-07-02 Thread Viktor Dukhovni via Postfix-users
On Sun, Jul 02, 2023 at 07:51:11PM -0400, joe a via Postfix-users wrote:

> >>   >> When attempting to send an email to postfix on that box, for delivery 
> >> >to
> >>   >> the local dovecot (via lmtp), the message instead goes out to my ISP 
> >> in
> >>   >> the fashion of currently working email se[r]ver.
> >>   >
> >>   >
> >> https://www.postfix.org/BASIC_CONFIGURATION_README.html#mydestination
> >>   >https://www.postfix.org/VIRTUAL_README.html#canonical
> >>   >https://www.postfix.org/BASIC_CONFIGURATION_README.html#relayhost

Your questions are adequately covered in the above if your needs are not
particularly sophisticated.

> Yet, my still light experience with postfix, leads me to believe
> having "relay host" undefined allows delivery to "the internet" if
> other "targets" have not been defined or "computable".
> Per docs:  relayhost =(default: direct delivery to Internet)

As documented "relayhost", when non-empty, is the default nexthop for
*remote* deliveries.  It has no effect on local delivery (be it for
"local" or "virtual mailbox" domains) or when an explicit nexthop
is specified by other means (see second table at):

http://www.postfix.org/ADDRESS_REWRITING_README.html#resolve

> So, since "mydestination" did not define any local domains, the next 
> destination, in this case, would be "the internet".

Yes, or in Postfix terms the "default" address class and its associated
"default_transport".  The list of nexthop sources in descending
precedence order is then (from the linked table):

transport_maps, sender_dependent_default_transport_maps,
default_transport, sender_dependent_relayhost_maps, relayhost,
recipient domain

Any explicit nexthop will override "relayhost", which only overrides the
implicit nexthop based on the recipient domain.

-- 
Viktor.
___
Postfix-users mailing list -- postfix-users@postfix.org
To unsubscribe send an email to postfix-users-le...@postfix.org


[pfx] Re: Postfix sending to undefined (?)

2023-07-02 Thread joe a via Postfix-users

On 7/2/2023 7:07 PM, Viktor Dukhovni via Postfix-users wrote:

On Sun, Jul 02, 2023 at 06:49:53PM -0400, joe a via Postfix-users wrote:


  > Viktor Dukhovni via Postfix-users Sun, 02 Jul 2023 14:21:52 -0700
  >
  >On Sun, Jul 02, 2023 at 05:11:52PM -0400, joe a via Postfix-users >wrote:
  >
  >> When attempting to send an email to postfix on that box, for delivery >to
  >> the local dovecot (via lmtp), the message instead goes out to my ISP in
  >> the fashion of currently working email se[r]ver.
  >
  >https://www.postfix.org/BASIC_CONFIGURATION_README.html#mydestination
  >https://www.postfix.org/VIRTUAL_README.html#canonical
  >https://www.postfix.org/BASIC_CONFIGURATION_README.html#relayhost

Delivery issue appears to have been to undefined relay_domains and
relayhost.


Seems unlikely, since you were expecting final delivery on the same
machine, and that should never depend on DNS, relay_domains or
relayhost.


Well, I admit to being confused, befuddled and bewildered. That was my 
thinking originally, yet, I could not deny the results of the changes I 
made.


However, I was wrong, yet again.  Reverting my changes, I realized that
I had also altered "mydestination" to include the domains being tested. 
Reverting the other changes, shows that "mydestination" seems to have 
resolved the problem.



I now suspect the "wrong destination" was accounted for by a postfix
DNS lookup to resolve that on it's own?  No pun intended.


No.  If you're expecting final delivery via LMTP on the same machine,
then the recipient address needs to ultimately resove to the "local"
or "virtual mailbox" address class, and be delivered via local(8)
(possibly handing off to mailbox_transport, ...) or via
virtaul_transport (be it virtual(8) or "lmtp").



Yet, my still light experience with postfix, leads me to believe having 
"relay host" undefined allows delivery to "the internet" if other 
"targets" have not been defined or "computable".

Per docs:  relayhost =(default: direct delivery to Internet)

So, since "mydestination" did not define any local domains, the next 
destination, in this case, would be "the internet".  The only way this 
machine could have known where to deliver the mail was via MX record.  I 
hope, anyway!  Machine "ESP" would be very scary indeed.


Anyway, not my intent to annoy or belabor, just to gain insight.
Given how configurable postfix is, that may be a lifetime's work.

Thanks for all your assistance.

joe a.
___
Postfix-users mailing list -- postfix-users@postfix.org
To unsubscribe send an email to postfix-users-le...@postfix.org


[pfx] Re: Postfix sending to undefined (?)

2023-07-02 Thread Viktor Dukhovni via Postfix-users
On Sun, Jul 02, 2023 at 06:49:53PM -0400, joe a via Postfix-users wrote:

>  > Viktor Dukhovni via Postfix-users Sun, 02 Jul 2023 14:21:52 -0700
>  >
>  >On Sun, Jul 02, 2023 at 05:11:52PM -0400, joe a via Postfix-users >wrote:
>  >
>  >> When attempting to send an email to postfix on that box, for delivery >to
>  >> the local dovecot (via lmtp), the message instead goes out to my ISP in
>  >> the fashion of currently working email se[r]ver.
>  >
>  >https://www.postfix.org/BASIC_CONFIGURATION_README.html#mydestination
>  >https://www.postfix.org/VIRTUAL_README.html#canonical
>  >https://www.postfix.org/BASIC_CONFIGURATION_README.html#relayhost
> 
> Delivery issue appears to have been to undefined relay_domains and
> relayhost.

Seems unlikely, since you were expecting final delivery on the same
machine, and that should never depend on DNS, relay_domains or
relayhost.

> I now suspect the "wrong destination" was accounted for by a postfix
> DNS lookup to resolve that on it's own?  No pun intended.

No.  If you're expecting final delivery via LMTP on the same machine,
then the recipient address needs to ultimately resove to the "local"
or "virtual mailbox" address class, and be delivered via local(8)
(possibly handing off to mailbox_transport, ...) or via
virtaul_transport (be it virtual(8) or "lmtp").

-- 
Viktor.
___
Postfix-users mailing list -- postfix-users@postfix.org
To unsubscribe send an email to postfix-users-le...@postfix.org


[pfx] Re: Postfix sending to undefined (?)

2023-07-02 Thread joe a via Postfix-users

> Viktor Dukhovni via Postfix-users Sun, 02 Jul 2023 14:21:52 -0700
>
>On Sun, Jul 02, 2023 at 05:11:52PM -0400, joe a via Postfix-users >wrote:
>
>> When attempting to send an email to postfix on that box, for 
delivery >to
>> the local dovecot (via lmtp), the message instead goes out to my ISP 
>in

>> the fashion of currently working email se[r]ver.
>
>
>https://www.postfix.org
>/BASIC_CONFIGURATION_README.html#mydestination
>https://www.postfix.org/VIRTUAL_README.html#canonical
>https://www.postfix.org/BASIC_CONFIGURATION_README.html#relayhost
>
>Viktor.
>

Thanks for the reminders.

Delivery issue appears to have been to undefined
relay_domains and relayhost

I now suspect the "wrong destination" was accounted for by a postfix DNS 
lookup to resolve that on it's own?  No pun intended.


joe a.
___
Postfix-users mailing list -- postfix-users@postfix.org
To unsubscribe send an email to postfix-users-le...@postfix.org


[pfx] Re: Postfix sending to undefined (?) relay

2023-07-02 Thread Viktor Dukhovni via Postfix-users
On Sun, Jul 02, 2023 at 05:11:52PM -0400, joe a via Postfix-users wrote:

> When attempting to send an email to postfix on that box, for delivery to 
> the local dovecot (via lmtp), the message instead goes out to my ISP in 
> the fashion of currently working email se[r]ver.

https://www.postfix.org/BASIC_CONFIGURATION_README.html#mydestination
https://www.postfix.org/VIRTUAL_README.html#canonical
https://www.postfix.org/BASIC_CONFIGURATION_README.html#relayhost

Most likely a failure to list the recipient domain in one of:

mydestination
virtual_mailbox_domains
virtual_alias_domains

To elicit specific advice:

https://www.postfix.org/DEBUG_README.html#mail

specifically post verbatim output (with all linebreaks and
whitespace preserved) from each of:

$ postconf -nf
$ postconf -Mf

plus mail logs for the "misrouted" delivery.

-- 
Viktor.
___
Postfix-users mailing list -- postfix-users@postfix.org
To unsubscribe send an email to postfix-users-le...@postfix.org