Re: restricted inbound on 587
On Sat, Jan 16, 2021 at 11:37:50PM -0700, Gary Aitken wrote: > >> /etc/postfix/master.cf: > >> #smtp inet n - y - - smtpd > >> submission inet n - y - - smtpd > > > > This looks like a submission service, so you would generally require > > TLS. > > Yes, I assume that's a hint I need >smtp_use_tls=yes No, that's the obsolete syntax to enable opportunistic outbound (SMTP client) TLS, but you need mandatory inbound (SMTP server) TLS. smtpd_tls_security_level = encrypt > Do I need others besides smtp_tls_cert_file and smtp_tls_key_file? Neither have anything to do with inbound TLS, and you generally don't need client certificates. The right parameters are: smtpd_tls_cert_file smtpd_tls_key_file and if you have both the cert and the key in the same file then just the "cert" one will do. > > You have nothing in your configuration that would direct outbound > > traffic to port 587, and it is likely not what you want anyway. > > Does "xx.com" really receive inbound email on port 587? If so, > > you'd need a transport table entry to send it there, and probably > > SASL to authenticate your access to that service. > > In this case the destination address does listen on 587. > Why is it not likely what I want? Because you did not explain that this is a relayhost. Your message said that you sent outbound mail to just that domain, not that you were using that domain as a relayhost. Which is it? > The recipient domain is not listed in mydestination; but shouldn't it be > contacting the MX host of the recipient domain rather than itself? Now you're really confusing things. If you want delivery to port 587 of a relayhost (submission service smarthost that figures how where to route the mail), then the MX records of the recipient domain are irrelevant. If you want to deliver to the MX host of domain you'd want to use port 25, which is where domains receive inbound mail. It seems you're rather confused abou†what you want... > The book seems likely to be horribly out of date, unfortunately. The books is more than sufficiently current on the fundamentals. Postfix configurations that worked in 2001 still work largely unchanged today, and your difficulties are with the concepts, not configuration specifics. -- Viktor.
Re: Conditional relayhost based on message size
On 16 Jan 2021, at 02:48, Viktor Dukhovni wrote: > Since the queue manager has no mechanism for size-dependent selection of > a default transport Postfix does, however, know the size of the message based if it is over or under the message_size_limit, and it must know that before the message hits the question manager, right? Mightn't it be possible to hook into that size check pre-queue without. Great deal of faff? -- C code. C code run. Run, code, run.
Re: restricted inbound on 587
On 1/16/21 4:08 PM, Viktor Dukhovni wrote:
On Sat, Jan 16, 2021 at 03:11:58PM -0700, Gary Aitken wrote:
I'm trying to set up a postfix-server on a google-compute-engine vm that works
as follows:
* outgoing mail from local machine (aaa.xxx.com) to a select few specific
addresses and any address on a specific domain (yyy.com)
* incoming mail from a single domain only (yyy.com)
DNS is set with MX as aaa.xxx.com, although the IP on the ipv4 interface is
an internal google address, not the one returned for aaa.xxx.com.
I've set the following:
/etc/aliases
postmaster: root
root: m...@yyy.com
foo-admin:u...@yyy.com,u...@yyy.com
/etc/mailname:
xxx.com
/etc/postfix/access
xxx.com OK
yyy.com OK
*5.2.1 No incoming mail allowed
You say *outgoing* mail to these domains, but from which sources?
Just "mynetworks"?
Yes
mynetworks = 127.0.0.0/8 [:::127.0.0.0]/104 [::1]/128 yyy.com
Do I need to explicitly add xxx.com, even though it is 127.0.0.0?
/etc/postfix/main.cf:
smtpd_tls_cert_file=/path/to/fullchain.pem
smtpd_tls_key_file=/path/to/privkey.pem
smtpd_use_tls=yes
smtpd_tls_session_cache_database = btree:${data_directory}/smtpd_scache
It seems you intend to receive some mail via inbound SMTP...
yes, on port 587.
recipient_restrictions = check_recipient_access hash:/etc/postfix/access
There is no such parameter in Postfix. Perhaps you wanted
"smtpd_recipient_restrictions".
Yes, typo in the original message
Is there a way to specify this in main.cf, or only in master.cf?
* If you're using Postfix >= 3.3, unless $compatibility_level
is set to a value > 0, the default "smtpd_relay_restrictions"
is empty, and the above configuration will fail for lack of
"reject-by-default" relay control.
postfix 3.3.0-1
* With Postfix 2.10 through 3.2, or compatibility_level >= 1,
With the default "smtpd_relay_restrictions", this allows outbound
mail from just mynetworks.
compatibility_level = 2
yes, I only want outbound from mynetworks
However, the default relay restrictions "defer" unauthorised relay
attempts, you should generally "reject" once the configuration is
deemed correct.
I thought the above /etc/postfix/access should do that?
xxx.com OK
yyy.com OK
*5.2.1 No incoming mail allowed
smtp_tls_session_cache_database = btree:${data_directory}/smtp_scache
smtp_tls_security_level = may
smtp_tls_loglevel=2
This TLS log level is too verbose for anything other than expert
debugging. Set it back to 1.
Happily...
I think I was seeing minimal output, which was why I bumped it up.
smtp_tls_relay_restrictions = permit_mynetworks permit_sasl_authenticated
defer_unauth_destination
What is this?
typo, error in transcription, should have been:
smtpd_relay_restrictions = permit_mynetworks permit_sasl_authenticated
defer_unauth_destination
however, that was left-over from I'm not sure where and should probably be
smtpd_relay_restrictions = permit_mynetworks reject_unauth_destination
mynetworks = 127.0.0.0/8 [:::127.0.0.0]/104 [::1]/128 yyy.com
Hostnames in mynetworks are fragile, and not recommended, don't recall
whether they're still supported, but even if they are, you should not
use them. So no "yyy.com" here.
thanks.
/etc/postfix/master.cf:
#smtp inet n - y - - smtpd
submission inet n - y - - smtpd
This looks like a submission service, so you would generally require
TLS.
Yes, I assume that's a hint I need
smtp_use_tls=yes
Do I need others besides smtp_tls_cert_file and smtp_tls_key_file?
When I attempt to send mail out using the mail command, the log shows:
Jan 16 21:20:05 ggg postfix/qmgr[13811]: 3CF5C3F3A5: from=,
size=423, nrcpt=1 (queue active)
Jan 16 21:20:05 ggg postfix/smtp[13860]: initializing the client-side TLS engine
Jan 16 21:20:06 ggg postfix/smtp[13820]: connect to xxx.com[a.b.c.d]:25:
Connection timed out
Jan 16 21:20:06 ggg postfix/smtp[13829]: connect to xxx.com[a.b.c.d]:25:
Connection timed out
questions:
1. Why is it attempting to send mail on port 25 and not 587?
You have nothing in your configuration that would direct outbound
traffic to port 587, and it is likely not what you want anyway.
Does "xx.com" really receive inbound email on port 587? If so,
you'd need a transport table entry to send it there, and probably
SASL to authenticate your access to that service.
In this case the destination address does listen on 587.
Why is it not likely what I want?
When specified as relayhost, the postfix process delivers the mail to the
(same) relayhost as a destination just fine.
2. Why is it trying to connect to itself (xxx.com)?
Note: the interface IP addr is of an internal
Re: restricted inbound on 587
On 1/16/21 4:04 PM, Jaroslaw Rafa wrote: Dnia 16.01.2021 o godz. 15:11:58 Gary Aitken pisze: 1. Why is it attempting to send mail on port 25 and not 587? Because that's the usual port MTA tries to connect to when sending mail. You didn't specify anywhere in your configuration that there should be a connection to port 587. I thought the changes to master.cf (commenting out smtp and uncommenting submission) changed that? If not, how do I set outgoing to 587 only? 2. Why is it trying to connect to itself (xxx.com)? Because you are trying to send mail to u...@xxx.com, MX for xxx.com is aaa.xxx.com and your server knows from the "myhostname" entry in the config file that it is aaa.xxx.com. So it tries to connect to itself. Somehow I would have thought it would use the loopback / localhost for that? Note: the interface IP addr is of an internal google network, not the external DNS address which points to this machine. Did you do the DNS query for "aaa.xxx.com" from this very machine or from somewhere else? This machine probably has configured somewhere (in /etc/hosts for example) the translation of aaa.xxx.com to this internal address. Or the DNS from inside Google cloud just returns different results than from outside. The DNS values were verified from outside the google network. 3. If I add the line: relayhost = [ok.relay.com]:587 mail gets delivered although mail to valid-u...@relay.com does not get delivered without the relayhost directive. Why not? And what is the error message? Is the domain "relay.com" not resolved? Then again, it may be due to DNS working differently from inside Google cloud than from outside. But it's hard to tell without the exact error message with which the message was rejected. I don't see any incoming traffic on port 587 at all. Thanks for the questions, and any further answers, Gary
Re: restricted inbound on 587
On Sat, Jan 16, 2021 at 03:11:58PM -0700, Gary Aitken wrote:
> I'm trying to set up a postfix-server on a google-compute-engine vm that
> works as follows:
>
> * outgoing mail from local machine (aaa.xxx.com) to a select few specific
>addresses and any address on a specific domain (yyy.com)
> * incoming mail from a single domain only (yyy.com)
>
> DNS is set with MX as aaa.xxx.com, although the IP on the ipv4 interface is
> an internal google address, not the one returned for aaa.xxx.com.
>
> I've set the following:
>/etc/aliases
> postmaster: root
> root: m...@yyy.com
> foo-admin:u...@yyy.com,u...@yyy.com
>
>/etc/mailname:
> xxx.com
>
>/etc/postfix/access
> xxx.com OK
> yyy.com OK
> *5.2.1 No incoming mail allowed
You say *outgoing* mail to these domains, but from which sources?
Just "mynetworks"?
>/etc/postfix/main.cf:
> smtpd_tls_cert_file=/path/to/fullchain.pem
> smtpd_tls_key_file=/path/to/privkey.pem
> smtpd_use_tls=yes
> smtpd_tls_session_cache_database = btree:${data_directory}/smtpd_scache
It seems you intend to receive some mail via inbound SMTP...
> recipient_restrictions = check_recipient_access hash:/etc/postfix/access
There is no such parameter in Postfix. Perhaps you wanted
"smtpd_recipient_restrictions".
* If you're using Postfix >= 3.3, unless $compatibility_level
is set to a value > 0, the default "smtpd_relay_restrictions"
is empty, and the above configuration will fail for lack of
"reject-by-default" relay control.
* With Postfix 2.10 through 3.2, or compatibility_level >= 1,
With the default "smtpd_relay_restrictions", this allows outbound
mail from just mynetworks.
However, the default relay restrictions "defer" unauthorised relay
attempts, you should generally "reject" once the configuration is
deemed correct.
> smtp_tls_session_cache_database = btree:${data_directory}/smtp_scache
> smtp_tls_security_level = may
> smtp_tls_loglevel=2
This TLS log level is too verbose for anything other than expert
debugging. Set it back to 1.
> smtp_tls_relay_restrictions = permit_mynetworks
> permit_sasl_authenticated defer_unauth_destination
What is this?
> mynetworks = 127.0.0.0/8 [:::127.0.0.0]/104 [::1]/128 yyy.com
Hostnames in mynetworks are fragile, and not recommended, don't recall
whether they're still supported, but even if they are, you should not
use them. So no "yyy.com" here.
>/etc/postfix/master.cf:
> #smtp inet n - y - - smtpd
> submission inet n - y - - smtpd
This looks like a submission service, so you would generally require
TLS.
> When I attempt to send mail out using the mail command, the log shows:
> Jan 16 21:20:05 ggg postfix/qmgr[13811]: 3CF5C3F3A5: from=,
> size=423, nrcpt=1 (queue active)
> Jan 16 21:20:05 ggg postfix/smtp[13860]: initializing the client-side TLS
> engine
> Jan 16 21:20:06 ggg postfix/smtp[13820]: connect to xxx.com[a.b.c.d]:25:
> Connection timed out
> Jan 16 21:20:06 ggg postfix/smtp[13829]: connect to xxx.com[a.b.c.d]:25:
> Connection timed out
>
> questions:
>1. Why is it attempting to send mail on port 25 and not 587?
You have nothing in your configuration that would direct outbound
traffic to port 587, and it is likely not what you want anyway.
Does "xx.com" really receive inbound email on port 587? If so,
you'd need a transport table entry to send it there, and probably
SASL to authenticate your access to that service.
>2. Why is it trying to connect to itself (xxx.com)?
> Note: the interface IP addr is of an internal google network,
> not the external DNS address which points to this machine.
Because the recipient domain is not listed in mydestination, or
virtual_mailbox_domains, and the MX host of the recipient domain
(or the domain itself otherwise) is "xxx.com".
The Postfix book by Ralf and Patrick is probably a good first
resource if the material in:
http://www.postfix.org/BASIC_CONFIGURATION_README.html
http://www.postfix.org/STANDARD_CONFIGURATION_README.html
http://www.postfix.org/SOHO_README.html
assumes more background than you already have.
--
Viktor.
Re: restricted inbound on 587
Dnia 16.01.2021 o godz. 15:11:58 Gary Aitken pisze: > 1. Why is it attempting to send mail on port 25 and not 587? Because that's the usual port MTA tries to connect to when sending mail. You didn't specify anywhere in your configuration that there should be a connection to port 587. > 2. Why is it trying to connect to itself (xxx.com)? Because you are trying to send mail to u...@xxx.com, MX for xxx.com is aaa.xxx.com and your server knows from the "myhostname" entry in the config file that it is aaa.xxx.com. So it tries to connect to itself. > Note: the interface IP addr is of an internal google network, >not the external DNS address which points to this machine. Did you do the DNS query for "aaa.xxx.com" from this very machine or from somewhere else? This machine probably has configured somewhere (in /etc/hosts for example) the translation of aaa.xxx.com to this internal address. Or the DNS from inside Google cloud just returns different results than from outside. > 3. If I add the line: >relayhost = [ok.relay.com]:587 > mail gets delivered > although mail to valid-u...@relay.com does not get delivered > without the relayhost directive. Why not? And what is the error message? Is the domain "relay.com" not resolved? Then again, it may be due to DNS working differently from inside Google cloud than from outside. But it's hard to tell without the exact error message with which the message was rejected. -- Regards, Jaroslaw Rafa r...@rafa.eu.org -- "In a million years, when kids go to school, they're gonna know: once there was a Hushpuppy, and she lived with her daddy in the Bathtub."
restricted inbound on 587
I'm trying to set up a postfix-server on a google-compute-engine vm that works
as follows:
outgoing mail from local machine (aaa.xxx.com) to a select few specific
addresses and any address on a specific domain (yyy.com)
incoming mail from a single domain only (yyy.com)
DNS is set with MX as aaa.xxx.com, although the IP on the ipv4 interface is
an internal google address, not the one returned for aaa.xxx.com.
I've set the following:
/etc/aliases
postmaster: root
root: m...@yyy.com
foo-admin:u...@yyy.com,u...@yyy.com
/etc/mailname:
xxx.com
/etc/postfix/access
xxx.com OK
yyy.com OK
*5.2.1 No incoming mail allowed
/etc/postfix/main.cf:
smtpd_tls_cert_file=/path/to/fullchain.pem
smtpd_tls_key_file=/path/to/privkey.pem
smtpd_use_tls=yes
smtpd_tls_session_cache_database = btree:${data_directory}/smtpd_scache
smtp_tls_session_cache_database = btree:${data_directory}/smtp_scache
smtp_tls_security_level = may
smtp_tls_loglevel=2
smtp_tls_relay_restrictions = permit_mynetworks permit_sasl_authenticated
defer_unauth_destination
myhostname = aaa.xxx.com
alias_maps = hash:/etc/aliases
alias_database = hash:/etc/aliases
myorigin = /etc/mailname
mydestination = $myhostname, ggg.c.projectname.internal,
localhost.c.projectname.internal, localhost
relay_domains =
mynetworks = 127.0.0.0/8 [:::127.0.0.0]/104 [::1]/128 yyy.com
recipient_restrictions = check_recipient_access hash:/etc/postfix/access
inet_interfaces = all
inet_protocols = all
recipient_delimiter = +
/etc/postfix/master.cf:
#smtp inet n - y - - smtpd
submission inet n - y - - smtpd
When I attempt to send mail out using the mail command, the log shows:
Jan 16 21:20:05 ggg postfix/qmgr[13811]: 3CF5C3F3A5: from=,
size=423, nrcpt=1 (queue active)
Jan 16 21:20:05 ggg postfix/smtp[13860]: initializing the client-side TLS engine
Jan 16 21:20:06 ggg postfix/smtp[13820]: connect to xxx.com[a.b.c.d]:25:
Connection timed out
Jan 16 21:20:06 ggg postfix/smtp[13829]: connect to xxx.com[a.b.c.d]:25:
Connection timed out
questions:
1. Why is it attempting to send mail on port 25 and not 587?
2. Why is it trying to connect to itself (xxx.com)?
Note: the interface IP addr is of an internal google network,
not the external DNS address which points to this machine.
3. If I add the line:
relayhost = [ok.relay.com]:587
mail gets delivered
although mail to valid-u...@relay.com does not get delivered
without the relayhost directive. Why not?
Thanks for any guidance,
Gary
Re: Conditional relayhost based on message size
Viktor Dukhovni: > On Sat, Jan 16, 2021 at 04:48:22AM -0500, Viktor Dukhovni wrote: > > > On Sat, Jan 16, 2021 at 08:14:34AM +, Alexander wrote: > > > > > My goal is to conditionally select the relayhost based on the total size > > > of the outgoing message. The rationale is that I'm using Amazon AWS SES > > > for the most part. Alas, SES only accepts messages up to 10 MB in size > > > (this includes images and attachments that are part of the message), and > > > when the outgoing message exceeds that size, it will be bounced. > > > > > > Any tips for filters or tools that would help me define another > > > relayhost based on the outgoing message size would be greatly > > > appreciated! > > > > Since the queue manager has no mechanism for size-dependent selection of > > a default transport (with the help of trivial-rewrite), the only way > > handle this deterministically in Postfix is to shunt large messages into > > a separate instance, which can be done in a number of ways, but is not > > particularly simple or elegant. > > For this to be naturally supported in Postfix, we'd need a new feature, > namely a variant of "FILTER" that overrides *just* the default_transport, > making it possible to use more general criteria than "sender-dependent" > for default_transport selection. > > Possible design: > > 1. New access(5) verb taking an associated transport value that > triggers such an override. > 2. New queue-file record type holding the default-transport > override. > 3. Queue manager loads this record into memory in the same way > as "FILTER". If both are present, "FILTER" wins. > 4. Queue manager sends its value along with all trivial-rewrite > "resolve" requests. > 5. trivial-rewrite uses this default transport rather than > $default_transport when the destination domain is not > in any of the more specific address classes, and there > is no explicit transport(5) mapping for the recipient. > > This would be primarily useful only when using a relayhost, subject to > secondary criteria to divert some messages to a different transport > and/or nexthop based on ad-hoc message features detected during > message reception. The difference from "FILTER" is that messages > to local recipients are not affected. > > I am not sure whether adding such a feature motivated by just the > presented use-case is warranted. My take: not if it only solves only one problem. For example, I have several notes on making the scheduling (within a delivery transport) dependent on a concept of 'cost', which could be one "number of delivery requests with similar sender or domain", "message size", "number of delivery requests with similar receiver or domain", or some weighted combination. Just compute a cost and schedule as appropriate for that cost bucket. If we make routing dependent on message properties, we could take a page from trivial-rewrite which has two flavors of routing, one for probes and one for non-probes. We could have N flavors of routing and select the flavor based on the weighted computation of something. Wietse
Re: Conditional relayhost based on message size
On Sat, Jan 16, 2021 at 04:48:22AM -0500, Viktor Dukhovni wrote: > On Sat, Jan 16, 2021 at 08:14:34AM +, Alexander wrote: > > > My goal is to conditionally select the relayhost based on the total size > > of the outgoing message. The rationale is that I'm using Amazon AWS SES > > for the most part. Alas, SES only accepts messages up to 10 MB in size > > (this includes images and attachments that are part of the message), and > > when the outgoing message exceeds that size, it will be bounced. > > > > Any tips for filters or tools that would help me define another > > relayhost based on the outgoing message size would be greatly > > appreciated! > > Since the queue manager has no mechanism for size-dependent selection of > a default transport (with the help of trivial-rewrite), the only way > handle this deterministically in Postfix is to shunt large messages into > a separate instance, which can be done in a number of ways, but is not > particularly simple or elegant. For this to be naturally supported in Postfix, we'd need a new feature, namely a variant of "FILTER" that overrides *just* the default_transport, making it possible to use more general criteria than "sender-dependent" for default_transport selection. Possible design: 1. New access(5) verb taking an associated transport value that triggers such an override. 2. New queue-file record type holding the default-transport override. 3. Queue manager loads this record into memory in the same way as "FILTER". If both are present, "FILTER" wins. 4. Queue manager sends its value along with all trivial-rewrite "resolve" requests. 5. trivial-rewrite uses this default transport rather than $default_transport when the destination domain is not in any of the more specific address classes, and there is no explicit transport(5) mapping for the recipient. This would be primarily useful only when using a relayhost, subject to secondary criteria to divert some messages to a different transport and/or nexthop based on ad-hoc message features detected during message reception. The difference from "FILTER" is that messages to local recipients are not affected. I am not sure whether adding such a feature motivated by just the presented use-case is warranted. -- Viktor.
Re: Conditional relayhost based on message size
On Sat, Jan 16, 2021 at 08:14:34AM +, Alexander wrote: > My goal is to conditionally select the relayhost based on the total size > of the outgoing message. The rationale is that I'm using Amazon AWS SES > for the most part. Alas, SES only accepts messages up to 10 MB in size > (this includes images and attachments that are part of the message), and > when the outgoing message exceeds that size, it will be bounced. > > Any tips for filters or tools that would help me define another > relayhost based on the outgoing message size would be greatly > appreciated! Since the queue manager has no mechanism for size-dependent selection of a default transport (with the help of trivial-rewrite), the only way handle this deterministically in Postfix is to shunt large messages into a separate instance, which can be done in a number of ways, but is not particularly simple or elegant. The simplest is perhaps to allow the message to route to AWS, where it would typically rejected in response to "MAIL FROM" when Postfix announces the message size, and to map that response to a tempfail, at which point the message would go the SMTP fallback relay for the transport, but this can be complex if amazon publishes many IP addresses for their submission service, since Postfix would try those first and may give up after a small number of connections. You'd therefore need to also ensure that the AWS relay resolves to just 1 IP address. That could be done with Python hooks in unbound, or a static IP (bypassing live DNS) that's updated out of band. If you want to take the second instance route, then it may be simplest to place large messages on hold, and within the same filesystem, move messages from the hold queue to the incoming queue of the second instance. Alternatively, an SMTP content_filter could dynamically choose the reinjection port based on message size, but you'd need to implement such an SMTP proxy. Finally, you could always try Exim. For sufficiently exotic requirements, though I'm generally loathe to recomment a complex monolithic MTA with a spotty security track record, it does offer a lot more conditional logic in its mail processing pipeline. You might even use Exim as a content_filter for Postfix, and have Postfix ultimately deliver the outbound message, with Exim routing the message to one of two Postfix instances. Though it is rather overkill if all you want is a size-dependent SMTP switch. -- Viktor.
Conditional relayhost based on message size
Hello, My goal is to conditionally select the relayhost based on the total size of the outgoing message. The rationale is that I'm using Amazon AWS SES for the most part. Alas, SES only accepts messages up to 10 MB in size (this includes images and attachments that are part of the message), and when the outgoing message exceeds that size, it will be bounced. Any tips for filters or tools that would help me define another relayhost based on the outgoing message size would be greatly appreciated! Alex
