Re: Reverse smtpd_sender_login_maps
On 2020-10-07 15:03, Vieri Di Paola wrote:
On Wed, Oct 7, 2020 at 2:34 PM Tom Sommer wrote:
So SASL user "t...@example.com" would be able to send only from
"@example.com".
smtpd_sender_login_maps = pcre:/etc/postfix/login_maps.pcre
content of /etc/postfix/login_maps.pcre:
/^(.*)@your(own)?domain\.org$/ ${1}
yea, this far I got. But I need the domain to be dynamic/wildcard (since
there are hundreds of thousands of domains).
---
Tom
Re: repeated connect and disconnect
On Thu, 8 Oct 2020 at 04:03, li...@lazygranch.com wrote: > > Is there something I should be doing to mitigate this problem? > > Oct 8 02:11:42 myserver postfix/smtpd[11630]: connect from > unknown[180.123.163.212] > Oct 8 02:11:43 myserver postfix/smtpd[11632]: connect from > unknown[180.123.163.212] > Oct 8 02:11:43 myserver postfix/smtpd[11632]: lost connection after EHLO > from unknown[180.123.163.212] > Oct 8 02:11:43 myserver postfix/smtpd[11632]: disconnect from > unknown[180.123.163.212] ehlo=1 commands=1 > ... > Oct 8 02:11:55 myserver postfix/smtpd[11632]: warning: Connection rate limit > exceeded: 11 from unknown[180.123.163.212] for service smtp > Oct 8 02:11:55 myserver postfix/smtpd[11632]: disconnect from > unknown[180.123.163.212] commands=0/0 > Oct 8 02:11:55 myserver postfix/smtpd[11630]: connect from > unknown[180.123.163.212] > Oct 8 02:11:55 myserver postfix/smtpd[11630]: warning: Connection rate limit > exceeded: 12 from unknown[180.123.163.212] for service smtp > Oct 8 02:11:55 myserver postfix/smtpd[11630]: disconnect from > unknown[180.123.163.212] commands=0/0 > Oct 8 02:15:15 myserver postfix/anvil[11633]: statistics: max connection > rate 12/60s for (smtp:180.123.163.212) at Oct 8 02:11:55 > Oct 8 02:15:15 myserver postfix/anvil[11633]: statistics: max connection > count 2 for (smtp:180.123.163.212) at Oct 8 02:11:43 > Oct 8 02:15:15 myserver postfix/anvil[11633]: statistics: max cache size 1 > at Oct 8 02:11:42 smtpd is doing what you told it to and apart from the crud in the log I don't think there is a problem. But otherwise, use postscreen + RBLs? This ip address is blocklisted by many RBLs, including zen.spamhaus.org.
Why I prefer Postfix to OpenSMTPD for most uses
I used to consider OpenSMTPD to be highly secure, until CVE-2020-8794 and CVE-2020-7247 came out. Both allow an attacker to execute arbitrary shell commands as root. Even though both of these attacks have been fixed, I am still not sure if it is possible for a compromised unprivileged OpenSMTPD process to escalate privileges by similar means. There is a workaround (setting a specific "mda wrapper" in the configuration file), but it is off by default, and disables delivery to commands and files. It turns out that not only is Postfix not vulnerable to either attack, but it is still not vulnerable even if an attacker has a 0-day exploit in one of the unprivileged Postfix processes. Command injection via MDAs (CVE-2020-7247) would not be possible because Postfix does not use a shell for delivery by default, and even when it does use a shell, the sanitization done by the local service replaces all metacharacters with underscores. Command injection via envelope files (CVE-2020-8794) would not be possible either, because Postfix uses the "safe" (rather than "exact") model for delivery status management. This means that commands and files are not stored in the envelope file, but rather read from ~/.forward during delivery. Taken together, the above factors make me trust Postfix far more when it comes to security, especially when local deliveries are enabled. I don't need to worry that a future vulnerability in Postfix will potentially allow others to execute arbitrary code as my user, whereas OpenSMTPD needs special configuration before I can be anywhere near as confident. Postfix has other advantages, too. Its sendmail(1) works even if the mail system is stopped, whereas OpenSMTPD's does not. Postfix also supports other security features, such as DANE, which are lacking in OpenSMTPD. Finally, Postfix has far more flexible authentication and header processing. Wietse Venema, thank you for your years of hard work on Postfix. If any of the OpenSMTPD developers read this, I hope it provides some ideas for improvement. Sincerely, Demi M. Obenour OpenPGP_0xB288B55FFF9C22C1.asc Description: application/pgp-keys OpenPGP_signature Description: OpenPGP digital signature
Re: Accessing the sending user from a canonical(5) table
On 10/6/20 4:23 PM, Wietse Venema wrote: Demi M. Obenour: On 10/6/20 12:46 PM, Wietse Venema wrote: For me, 'not found' also includes the case that the user is not found in the passwd file. By "allow 'not found' users", do you mean that such users will automatically be granted access, or that they will still be looked up (perhaps by numeric UID) in local_sender_login_maps? Postfix sendmail looks up the username only if no sender was specified with -f, and terminates if the username cannot be found. That behavior should not change by default. That's fine. If the feature is turned on then there should probably be a default action for users not listed in the table (deny or allow). Its not going to be pretty when only the numerical UID is avaialble (a 1:1 mapping username->sender would not make sense). What about defaulting to allow if local_sender_login_maps has its default value, and deny otherwise? That keeps the current default behavior, while still allowing administrators to lock it down. In the unlikely event that the table lookup itself fails, I believe that postdrop should log an error and exit. That avoids accidental security holes due to temporary failures. Wietse Sincerely, Demi OpenPGP_0xB288B55FFF9C22C1.asc Description: application/pgp-keys OpenPGP_signature Description: OpenPGP digital signature
repeated connect and disconnect
Is there something I should be doing to mitigate this problem? Oct 8 02:11:42 myserver postfix/smtpd[11630]: connect from unknown[180.123.163.212] Oct 8 02:11:43 myserver postfix/smtpd[11632]: connect from unknown[180.123.163.212] Oct 8 02:11:43 myserver postfix/smtpd[11632]: lost connection after EHLO from unknown[180.123.163.212] Oct 8 02:11:43 myserver postfix/smtpd[11632]: disconnect from unknown[180.123.163.212] ehlo=1 commands=1 Oct 8 02:11:44 myserver postfix/smtpd[11632]: connect from unknown[180.123.163.212] Oct 8 02:11:45 myserver postfix/smtpd[11632]: lost connection after EHLO from unknown[180.123.163.212] Oct 8 02:11:45 myserver postfix/smtpd[11632]: disconnect from unknown[180.123.163.212] ehlo=1 commands=1 Oct 8 02:11:45 myserver postfix/smtpd[11632]: connect from unknown[180.123.163.212] Oct 8 02:11:46 myserver postfix/smtpd[11632]: lost connection after EHLO from unknown[180.123.163.212] Oct 8 02:11:46 myserver postfix/smtpd[11632]: disconnect from unknown[180.123.163.212] ehlo=1 commands=1 Oct 8 02:11:46 myserver postfix/smtpd[11630]: lost connection after CONNECT from unknown[180.123.163.212] Oct 8 02:11:46 myserver postfix/smtpd[11630]: disconnect from unknown[180.123.163.212] commands=0/0 Oct 8 02:11:46 myserver postfix/smtpd[11632]: connect from unknown[180.123.163.212] Oct 8 02:11:47 myserver postfix/smtpd[11632]: lost connection after EHLO from unknown[180.123.163.212] Oct 8 02:11:47 myserver postfix/smtpd[11632]: disconnect from unknown[180.123.163.212] ehlo=1 commands=1 Oct 8 02:11:47 myserver postfix/smtpd[11630]: connect from unknown[180.123.163.212] Oct 8 02:11:48 myserver postfix/smtpd[11630]: lost connection after EHLO from unknown[180.123.163.212] Oct 8 02:11:48 myserver postfix/smtpd[11630]: disconnect from unknown[180.123.163.212] ehlo=1 commands=1 Oct 8 02:11:48 myserver postfix/smtpd[11632]: connect from unknown[180.123.163.212] Oct 8 02:11:48 myserver postfix/smtpd[11632]: lost connection after EHLO from unknown[180.123.163.212] Oct 8 02:11:48 myserver postfix/smtpd[11632]: disconnect from unknown[180.123.163.212] ehlo=1 commands=1 Oct 8 02:11:50 myserver postfix/smtpd[11630]: connect from unknown[180.123.163.212] Oct 8 02:11:53 myserver postfix/smtpd[11630]: lost connection after EHLO from unknown[180.123.163.212] Oct 8 02:11:53 myserver postfix/smtpd[11630]: disconnect from unknown[180.123.163.212] ehlo=1 commands=1 Oct 8 02:11:54 myserver postfix/smtpd[11632]: connect from unknown[180.123.163.212] Oct 8 02:11:54 myserver postfix/smtpd[11632]: lost connection after EHLO from unknown[180.123.163.212] Oct 8 02:11:54 myserver postfix/smtpd[11632]: disconnect from unknown[180.123.163.212] ehlo=1 commands=1 Oct 8 02:11:54 myserver postfix/smtpd[11630]: connect from unknown[180.123.163.212] Oct 8 02:11:55 myserver postfix/smtpd[11630]: lost connection after EHLO from unknown[180.123.163.212] Oct 8 02:11:55 myserver postfix/smtpd[11630]: disconnect from unknown[180.123.163.212] ehlo=1 commands=1 Oct 8 02:11:55 myserver postfix/smtpd[11632]: connect from unknown[180.123.163.212] Oct 8 02:11:55 myserver postfix/smtpd[11632]: warning: Connection rate limit exceeded: 11 from unknown[180.123.163.212] for service smtp Oct 8 02:11:55 myserver postfix/smtpd[11632]: disconnect from unknown[180.123.163.212] commands=0/0 Oct 8 02:11:55 myserver postfix/smtpd[11630]: connect from unknown[180.123.163.212] Oct 8 02:11:55 myserver postfix/smtpd[11630]: warning: Connection rate limit exceeded: 12 from unknown[180.123.163.212] for service smtp Oct 8 02:11:55 myserver postfix/smtpd[11630]: disconnect from unknown[180.123.163.212] commands=0/0 Oct 8 02:15:15 myserver postfix/anvil[11633]: statistics: max connection rate 12/60s for (smtp:180.123.163.212) at Oct 8 02:11:55 Oct 8 02:15:15 myserver postfix/anvil[11633]: statistics: max connection count 2 for (smtp:180.123.163.212) at Oct 8 02:11:43 Oct 8 02:15:15 myserver postfix/anvil[11633]: statistics: max cache size 1 at Oct 8 02:11:42 - postconf mail_version mail_version = 3.5.7 smtpd_client_auth_rate_limit = 20 smtpd_client_connection_count_limit = 10 smtpd_client_connection_rate_limit = 10 smtpd_client_new_tls_session_rate_limit = 3 smtpd_client_recipient_rate_limit = 40 smtpd_client_restrictions = permit_sasl_authenticated, permit_mynetworks, reject_unauth_destination, check_reverse_client_hostname_access pcre:/etc/postfix/fqrdns.pcre, reject_unknown_reverse_client_hostname, check_client_access hash:/etc/postfix/spamsources smtpd_error_sleep_time = 2s smtpd_hard_error_limit = 6 smtpd_helo_required = yes smtpd_milters = inet:127.0.0.1:8891, inet:127.0.0.1:8893 smtpd_recipient_limit = 20 smtpd_recipient_restrictions = permit_sasl_authenticated, permit_mynetworks, reject_unauth_destination, reject_unauth_pipelining, reject_non_fqdn_sender, reject_unknown_sender_domain, reject_unknow
Re: Forward email based on Regexps
On Wed, Oct 07, 2020 at 06:54:10PM -0400, Frank DiGennaro wrote: > Yet it will still match regardless, so what's your point? My point, and I am sorry if it is not welcome, is that a regular expression has to not only match the things it SHOULD match, it *also* needs to NOT match the things it SHOULD NOT match. The regular expressions you crafted fail the second requirement. You're of course more than free to not care, and even resent the helpful advice. -- Viktor.
RE: Forward email based on Regexps
Yet it will still match regardless, so what's your point? I'm sorry if my question was "beneath" you all and according to Wietz I "wasted" your time with my question but it's not obvious to anyone that \d is not supported. Bottom line, fuck you and all of you, I'm sorry that I wasted all of your time with such an elementary problem after I've provided ALL of the required data to solve the problem. FSD -Original Message- From: Viktor Dukhovni [mailto:postfix-us...@dukhovni.org] Sent: Wednesday, October 7, 2020 3:32 PM To: Frank DiGennaro Cc: Postfix users Subject: Re: Forward email based on Regexps > On Oct 7, 2020, at 5:24 PM, Frank DiGennaro wrote: > > I went back and made the changes Noel Jones suggested Like so. But these are not what Noel suggested: > /^[0-9]+@fax.mobilepbx.net/ asterisk > /^[0-9]+@mobilepbx.net/ asterisk > > This now works. Thank you very, very much. - The "." characters are NOT escaped, they should be "\." not just ".". - The domain name is not anchored at the end, it should be "\.net$" not "\.net" That is: /^[0-9]+@fax\.mobilepbx\.net$/ asterisk /^[0-9]+@mobilepbx\.net$/ asterisk And, you generally should specify an explicit "@domain" qualifier for the RHS "asterisk" result, though if you're sure that "$myorigin" will always continue to be the correct domain suffix, this will work as written. -- Viktor.
Re: Sender restriction to reject message with multiple from addresses
On Wed, Oct 07, 2020 at 10:35:39PM +, Pau Peris wrote: > Could you explain to me which would be the benefits of implementing > such behaviour on a filter or milter instead of doing it on > header_checks? As I wrote upthread, and you quoted in your message: > > RFC5322.From syntax is rather non-trivial, and trying to parse it with > > regular expressions is not a terribly good idea. While most addresses > > are simple, and you might not ever see the exceptions, I do not > > recommend ad-hoc half-right parsers for the mailbox syntax. It is non-trivial to craft robust regular expressions for RFC*22 mailbox syntax, not quite as bad as: https://stackoverflow.com/questions/1732348/regex-match-open-tags-except-xhtml-self-contained-tags/1732454#1732454 but naïve attempts are likely to fall short of the full grammar. It might be simpler to arrange for multi-recipient messages to the purported author of the message to be dropped, by passing mail submission from the Web form through an SMTP service that rejects all multi-recipient mail (and making sure that the envelope is not split before that happens). On the other hand, for a web contact form, if you want to only permit a single localpart@domain format, rather than any of the more general phrase "quoted-text" mailbox (comment) ... variants, then a regular expression becomes somewhat simpler, until you also need to handle EAI (non-ASCII localpart and/or domain), e.g. виктор1spam@духовный.org the possible forms are then: - dot-atom@domain - quoted-string@domain Where the first variant is matched by: # PCRE: ASCII dot-atom @ domain /^ (?: [^][()<>:;@\\,."\x00-\x20\x7f-\xff]+ \.)? [^][()<>:;@\\,."\x00-\x20\x7f-\xff]+ @ (?: [a-z\d]+ (-+[a-z\d]+)* \.)+ [a-z\d]+ (-+[a-z\d]+)* /x DUNNO # PCRE: quoted-string sans NUL @ domain /^ " ( [^\\"\x00]+ | \\[^\x00] )+ " @ (?: [a-z\d]+ (-+[a-z\d]+)* \.)+ [a-z\d]+ (-+[a-z\d]+)* /x DUNNO # Not a valid address /^/ whatever action is appropriate You may want to replace /^/ with /^From:\s*/ if this is header checks. Postfix does not currently support matching unicode with PCRE, so validating EAI addresses with pcre_table(5) may not yet be possible. > Also, do you know in which cases would be useful to allow or make use > of multiple From addresses? Just in case I'm missing something. > > Thanks in advanced, > > On Tue, Oct 6, 2020 at 10:50 PM Viktor Dukhovni > wrote: > > > > On Wed, Oct 07, 2020 at 12:27:09AM +, Pau Peris wrote: > > > > > I'm hosting my dad's webpage which has a contact form (which should be > > > improved to avoid spam and/or bots) and from time to time someone > > > types multiple email addresses in the from field of the form so > > > contact emails with multiple from addresses like "from: > > > h...@example.com, f...@example.net" are generated. I though that those > > > kind of messages should get rejected and thought that maybe there was > > > a builtin restriction for this use case. > > > > Therefore, the right solution would be in a content filter or milter, > > coupled with a solid email address (list) parsing library. -- Viktor.
Re: Sender restriction to reject message with multiple from addresses
Hi Viktor, thanks a lot for your opinion. Could you explain to me which would be the benefits of implementing such behaviour on a filter or milter instead of doing it on header_checks? Also, do you know in which cases would be useful to allow or make use of multiple From addresses? Just in case I'm missing something. Thanks in advanced, On Tue, Oct 6, 2020 at 10:50 PM Viktor Dukhovni wrote: > > On Wed, Oct 07, 2020 at 12:27:09AM +, Pau Peris wrote: > > > I'm hosting my dad's webpage which has a contact form (which should be > > improved to avoid spam and/or bots) and from time to time someone > > types multiple email addresses in the from field of the form so > > contact emails with multiple from addresses like "from: > > h...@example.com, f...@example.net" are generated. I though that those > > kind of messages should get rejected and thought that maybe there was > > a builtin restriction for this use case. > > You may of course choose to try to block such messages, but in terms of > general syntax, they are valid email messages: > > https://tools.ietf.org/html/rfc5322#section-3.6.2 > > The only constraint is that a message with multiple authors (multiple > "From" mailboxes), is required to have a "Sender" header which indicates > who is to blame for actually sending the message. The requirement is > unlikely to be enforced by most MUAs. I don't know what DMARC makes of > multi-author messages (but since I don't use, recommend or think much of > DMARC, I have much reason to care about that). > > RFC5322.From syntax is rather non-trivial, and trying to parse it with > regular expressions is not a terribly good idea. While most addresses > are simple, and you might not ever see the exceptions, I do not > recommend ad-hoc half-right parsers for the mailbox syntax. > > Therefore, the right solution would be in a content filter or milter, > coupled with a solid email address (list) parsing library. > > -- > Viktor. -- Pau Aquest correu electrònic conté informació de caràcter confidencial dirigida exclusivament al seu/s destinatari/s en còpia present. Tant mateix, queda prohibida la seva divulgació, copia o distribució a tercers sense prèvia autorització escrita per part de Pau Peris Rodriguez. En cas d'haver rebut aquesta informació per error, es demana que es notifiqui immediatament d'aquesta circumstancia mitjançant la direcció electrònica del emissor.
Re: Forward email based on Regexps
> On Oct 7, 2020, at 5:24 PM, Frank DiGennaro wrote: > > I went back and made the changes Noel Jones suggested Like so. But these are not what Noel suggested: > /^[0-9]+@fax.mobilepbx.net/ asterisk > /^[0-9]+@mobilepbx.net/ asterisk > > This now works. Thank you very, very much. - The "." characters are NOT escaped, they should be "\." not just ".". - The domain name is not anchored at the end, it should be "\.net$" not "\.net" That is: /^[0-9]+@fax\.mobilepbx\.net$/ asterisk /^[0-9]+@mobilepbx\.net$/ asterisk And, you generally should specify an explicit "@domain" qualifier for the RHS "asterisk" result, though if you're sure that "$myorigin" will always continue to be the correct domain suffix, this will work as written. -- Viktor.
RE: Forward email based on Regexps
Thanks for the heads up. I will do that. Regards; Frank -Original Message- From: owner-postfix-us...@postfix.org [mailto:owner-postfix-us...@postfix.org] On Behalf Of Viktor Dukhovni Sent: Wednesday, October 7, 2020 3:09 PM To: postfix-users@postfix.org Subject: Re: Forward email based on Regexps On Wed, Oct 07, 2020 at 02:44:47PM -0400, Frank DiGennaro wrote: > I apologize. I'm an idiot. I thought that I was showing you what I > did. I showed how I defined the virtual_alias_maps in man.cf, added > the regex's into the file 'virtual_users', and ran several tests such > as 'postmap -q 555...@mobilepbx.net > pcre:/etc/postfix/virtual_users'. What am I not showing? I appreciate all your help. Context matters. Piecing the puzzle together from isolated fragments of separate messages is too much to expect of those willing and able to help. Therefore, you may need to repeat yourself, by posting a single message, containing all the relevant information, that is, per: http://www.postfix.org/DEBUG_README.html#mail - Output of: postconf -nf - Output of: postconf -Mf - Logs showing what happened when you tested - A brief note stating what you expected instead A quick glance over the thread, shows that: - You have wildcard rules, keep in mind that virtual expansion is recursive, and the RHS of each rule is subject to further lookups until either there's no match, or the result is the same as the input. - You don't qualify your virtual(5) RHS values with an explicit domain. That's generally unwise. They'll get implicitly qualified with $myorigin, and perhaps then match some other pattern in the PCRE table? - Your regular expressions are sloppy, missing "^" and "$" anchors, fail to escape literal "." as "\.", ... While it may be simple to write regular expressions that match a particular input pattern, it is more difficult to write *correct* regular expressions that match *only* the desired pattern and not also lots of other patterns that should not be matched. - You posted no logs that showed the unexpected results, with a brief explanation of what you expected instead. -- Viktor.
RE: Forward email based on Regexps
I went back and made the changes Noel Jones suggested Like so.
/^[0-9]+@fax.mobilepbx.net/ asterisk
/^[0-9]+@mobilepbx.net/ asterisk
This now works. Thank you very, very much.
Regards;
FSD
-Original Message-
From: owner-postfix-us...@postfix.org [mailto:owner-postfix-us...@postfix.org]
On Behalf Of Noel Jones
Sent: Tuesday, October 6, 2020 6:24 PM
To: postfix-users@postfix.org
Subject: Re: Forward email based on Regexps
On 10/6/2020 3:56 PM, Frank DiGennaro wrote:
> Thanks for the reply. This is what I have in my 'virtual_users' file
> verbatim. I've even kept the domain names and users the same.
>
> # Regexp # User to forward to
> /\d{10,}@fax.mobilepbx.net/ asterisk (I've tried both
> \d{10,} and [0-9]{10,} without success)
\d is a pcre construct that not all regexp libraries recognize.
You should anchor the expression to prevent unexpected matches.
The result should have a domain (even if it's @localhost) to prevent surprises.
> /\[0-9]{10,}@mobilepbx.net/ asterisk
Escaping the first [ makes it match a literal "[" instead of a character class.
Don't do that.
/^[0-9]+@fax\.mobliepbx\.net$/ astr...@example.com
-- Noel Jones
> #/555...@mobilepbx.net/ asterisk (When I try a specific
> number like this, this does work)
> /.*@mobilepbx.net/mobilepbx
>
> /.*@voipbiz.org/ voipbiz
>
> /.*@contessa.net/ fr...@digennaro.com
>
>
> When I do a couple of tests, this is what I get.
>
> (10 digits) (No)
> postmap -q 555...@mobilepbx.net regexp:/etc/postfix/virtual_users
> mobilepbx
>
> (11 digits) (No)
> postmap -q ...@mobilepbx.net regexp:/etc/postfix/virtual_users
> mobilepbx
>
> (Yes)
> postmap -q nosuchu...@mobilepbx.net regexp:/etc/postfix/virtual_users
> mobilepbx
>
> (Yes)
> postmap -q supp...@voipbiz.org regexp:/etc/postfix/virtual_users
> voipbiz postmap -q nosuchu...@voipbiz.org
> regexp:/etc/postfix/virtual_users voipbiz
>
> (Yes)
> postmap -q nosuchu...@contessa.net regexp:/etc/postfix/virtual_users
>
> fr...@digennaro.com
>
> Thanks;
> Frank
>
>
> -Original Message-
> From: owner-postfix-us...@postfix.org
> [mailto:owner-postfix-us...@postfix.org] On Behalf Of Wietse Venema
> Sent: Tuesday, October 6, 2020 1:37 PM
> To: Postfix users
> Subject: Re: Forward email based on Regexps
>
> Frank DiGennaro:
>> All;
>>
>> I've made progress with this problem. By adding
>> virtual_alias_maps = regexp:/etc/postfix/virtual_users at the bottom
>> of main.cf and adding the regexps below, and running "postmap
>> /etc/postfix/virtual_users ", the two catch-alls work fine, but the
>> "longer" matches do not and ultimately they get delivered to the
>> catch-all
> address. I'm almost there. What am I missing?
>>
>> Thanks in advance;
>
> Maybe you can show what you did. It is easy to make regexp mistakes.
> Note that regexp and pcre tables are parsed in the specified order,
> and that the first match wins.
>
> You can test stuff with the postmap command.
>
> postmap -q email-address pcre:/path/to/file
>
> Wietse
>
Re: Forward email based on Regexps
On Wed, Oct 07, 2020 at 02:44:47PM -0400, Frank DiGennaro wrote: > I apologize. I'm an idiot. I thought that I was showing you what I did. I > showed how I defined the virtual_alias_maps in man.cf, added the regex's > into the file 'virtual_users', and ran several tests such as 'postmap -q > 555...@mobilepbx.net pcre:/etc/postfix/virtual_users'. What am I not > showing? I appreciate all your help. Context matters. Piecing the puzzle together from isolated fragments of separate messages is too much to expect of those willing and able to help. Therefore, you may need to repeat yourself, by posting a single message, containing all the relevant information, that is, per: http://www.postfix.org/DEBUG_README.html#mail - Output of: postconf -nf - Output of: postconf -Mf - Logs showing what happened when you tested - A brief note stating what you expected instead A quick glance over the thread, shows that: - You have wildcard rules, keep in mind that virtual expansion is recursive, and the RHS of each rule is subject to further lookups until either there's no match, or the result is the same as the input. - You don't qualify your virtual(5) RHS values with an explicit domain. That's generally unwise. They'll get implicitly qualified with $myorigin, and perhaps then match some other pattern in the PCRE table? - Your regular expressions are sloppy, missing "^" and "$" anchors, fail to escape literal "." as "\.", ... While it may be simple to write regular expressions that match a particular input pattern, it is more difficult to write *correct* regular expressions that match *only* the desired pattern and not also lots of other patterns that should not be matched. - You posted no logs that showed the unexpected results, with a brief explanation of what you expected instead. -- Viktor.
Re: Forward email based on Regexps
Frank DiGennaro:
> Thanks for the reply. This is what I have in my 'virtual_users' file
> verbatim. I've even kept the domain names and users the same.
>
> # Regexp # User to forward to
> /\d{10,}@fax.mobilepbx.net/ asterisk (I've tried both
Wietse:
> That is PCRE not REGEXP syntax.
Frank DiGennaro:
> Wietse;
> I made the change but no luck. What I don't understand is how some
> regex's work and others don't considering regex's themselves are so
simple.
> I mean, they should all work or they should all now work.
Wietse:
> If you show what you did. then I am sure that someone can explain what
> mistake you made. Otherwise this email thread is just a waste of time.
Frank DiGennaro:
> I apologize. I'm an idiot. I thought that I was showing you what I did. I
> showed how I defined the virtual_alias_maps in man.cf, added the regex's
> into the file 'virtual_users', and ran several tests such as 'postmap -q
> 555...@mobilepbx.net pcre:/etc/postfix/virtual_users'. What am I not
> showing? I appreciate all your help.
- The regexp or pcre table, instead of saying you made some change.
- The (postmap) command and output, instead of saying it does not work.
Wietse
RE: Forward email based on Regexps
I apologize. I'm an idiot. I thought that I was showing you what I did. I
showed how I defined the virtual_alias_maps in man.cf, added the regex's
into the file 'virtual_users', and ran several tests such as 'postmap -q
555...@mobilepbx.net pcre:/etc/postfix/virtual_users'. What am I not
showing? I appreciate all your help.
Thanks;
FSD
-Original Message-
From: owner-postfix-us...@postfix.org
[mailto:owner-postfix-us...@postfix.org] On Behalf Of Wietse Venema
Sent: Wednesday, October 7, 2020 2:26 PM
To: Postfix users
Subject: Re: Forward email based on Regexps
Frank DiGennaro:
> Thanks for the reply. This is what I have in my 'virtual_users' file
> verbatim. I've even kept the domain names and users the same.
>
> # Regexp # User to forward to
> /\d{10,}@fax.mobilepbx.net/ asterisk (I've tried both
Wietse:
> That is PCRE not REGEXP syntax.
Frank DiGennaro:
> Wietse;
> I made the change but no luck. What I don't understand is how some
> regex's work and others don't considering regex's themselves are so
simple.
> I mean, they should all work or they should all now work.
If you show what you did. then I am sure that someone can explain what
mistake you made. Otherwise this email thread is just a waste of time.
Wietse
Re: Forward email based on Regexps
Frank DiGennaro:
> Thanks for the reply. This is what I have in my 'virtual_users' file
> verbatim. I've even kept the domain names and users the same.
>
> # Regexp # User to forward to
> /\d{10,}@fax.mobilepbx.net/ asterisk (I've tried both
Wietse:
> That is PCRE not REGEXP syntax.
Frank DiGennaro:
> Wietse;
> I made the change but no luck. What I don't understand is how some
> regex's work and others don't considering regex's themselves are so simple.
> I mean, they should all work or they should all now work.
If you show what you did. then I am sure that someone can explain what
mistake you made. Otherwise this email thread is just a waste of time.
Wietse
RE: Forward email based on Regexps
Wietse;
I made the change but no luck. What I don't understand is how some
regex's work and others don't considering regex's themselves are so simple.
I mean, they should all work or they should all now work.
Thanks;
Frank
-Original Message-
From: owner-postfix-us...@postfix.org
[mailto:owner-postfix-us...@postfix.org] On Behalf Of Wietse Venema
Sent: Tuesday, October 6, 2020 6:07 PM
To: Postfix users
Subject: Re: Forward email based on Regexps
Frank DiGennaro:
> Thanks for the reply. This is what I have in my 'virtual_users' file
> verbatim. I've even kept the domain names and users the same.
>
> # Regexp # User to forward to
> /\d{10,}@fax.mobilepbx.net/ asterisk (I've tried both
That is PCRE not REGEXP syntax.
Wietse
Re: Reverse smtpd_sender_login_maps
On Wed, 7 Oct 2020 at 14:04, Vieri Di Paola wrote:
>
> On Wed, Oct 7, 2020 at 2:34 PM Tom Sommer wrote:
> >
> > So SASL user "t...@example.com" would be able to send only from
> > "@example.com".
>
> smtpd_sender_login_maps = pcre:/etc/postfix/login_maps.pcre
>
> content of /etc/postfix/login_maps.pcre:
> /^(.*)@your(own)?domain\.org$/ ${1}
>
> This would force sasl-authed user "me" to only send from
> m...@yourdomain.org or m...@yourowndomain.org.
> You can change the regex to allow from @domain instead.
If, for authenticated users, you also want to enforce an *exact match*
between the Envelope Sender and the mail address in the 'From:'
header, this is offered by the milter at
https://github.com/magcks/milterfrom (but I have not tested it).
To enforce a domain-only match between the Envelope Sender and the
mail address in the 'From:' header the only way I can think of is to
use DMARC with p=reject, which is a big hammer for the given nut. Can
postfwd help here?
Re: auto smtp_bind_address
Hi
Wietse thanks for replay - now I have that solutions
sender_dependent_default_transport_maps =
pcre:/etc/postfix/vipout.pcre,
1) memcache:/etc/postfix/memcache_sender_dependent_cache.cf,
2) memcache:/etc/postfix/memcache_sender_dependent_default_cache.cf
1) query to private IP for domains and group domains
query = SELECT IFNULL((SELECT transport_id FROM
postfix_domain_group_transports WHERE domain = '%d'), transport_id) as
transport_id FROM postfix_transports WHERE is_default = 1 AND host =
'smtp.defaultserver.pl'
2) query to default if not find in query up
query = select transport_id from postfix_transports where is_default = 1
and host = 'smtp.defaultserver.pl';
and default_destination_concurrency_limit = 20
On 07.10.2020 15:23, Wietse Venema wrote:
> natan:
>> Hello
>> I have such a solution:
>>
>> 1)One serwer to incomming
>> 2)One server to outgoing
>>
>> All Customers in their mail clients (outgoing) use adress: smtp.foobar.org
>>
>> In main.cf I use? smtp_bind_address - for default IP send
>> and sender_dependent_default_transport_maps (for indiwydual IP)
>> works fine.
>>
>> Is any change to "auto changing" IP in smtp_bind_address ?
>> I know this is a stupid question but I have some problem with throttling
>> with send e-mail to *.protection.outlook.com if I change IP in
>> smtp_bind_address (RBL, for example)
>>
>> I think about sharing users and group addresses for sending mail - but
>> maybe is simpler solution ?
> There is no single Poatfix parameter that could accomplish this,
> because this requires coordinated configuration for more than one
> Postfix service (trivial-rewrite and the Postfix SMTP client).
>
> /etc/postfix/main.cf
> sender_dependent_default_transport_maps =
> hash:/etc/postfix/sender_transport
>
> /etc/postfix/sender_transport
> @one.examplesmtp_one:
> @two.examplesmtp_two:
> @three.example smtp_two:
> ...
>
> Note that domains 'two.example' and 'three.example' share the same
> delivery transport.
>
> Each delivery transport has its own smtp_bind_address and smtp_helo_name.
> Each smtp_helo_name value needs a DNS A (or ) record that
> resolves to the corresponding smtp_bind_address value.
>
> /etc/postfix/master.cf
> smtp_one .. .. .. .. .. .. smtp
> -o smtp_bind_address=address-for-one
> -o smtp_helo_name=helo-for-one
> smtp_two .. .. .. .. .. .. smtp
> -o smtp_bind_address=address-for-two
> -o smtp_helo_name=helo-for-two
> ...
>
> Additionally, you may need to reduce process limits in master.cf,
> or have {smtp_one,smtp_two,...}_destination_concurrency_limit
> settings in main.cf.
>
> Wietse
--
Re: auto smtp_bind_address
natan:
> Hello
> I have such a solution:
>
> 1)One serwer to incomming
> 2)One server to outgoing
>
> All Customers in their mail clients (outgoing) use adress: smtp.foobar.org
>
> In main.cf I use? smtp_bind_address - for default IP send
> and sender_dependent_default_transport_maps (for indiwydual IP)
> works fine.
>
> Is any change to "auto changing" IP in smtp_bind_address ?
> I know this is a stupid question but I have some problem with throttling
> with send e-mail to *.protection.outlook.com if I change IP in
> smtp_bind_address (RBL, for example)
>
> I think about sharing users and group addresses for sending mail - but
> maybe is simpler solution ?
There is no single Poatfix parameter that could accomplish this,
because this requires coordinated configuration for more than one
Postfix service (trivial-rewrite and the Postfix SMTP client).
/etc/postfix/main.cf
sender_dependent_default_transport_maps =
hash:/etc/postfix/sender_transport
/etc/postfix/sender_transport
@one.examplesmtp_one:
@two.examplesmtp_two:
@three.example smtp_two:
...
Note that domains 'two.example' and 'three.example' share the same
delivery transport.
Each delivery transport has its own smtp_bind_address and smtp_helo_name.
Each smtp_helo_name value needs a DNS A (or ) record that
resolves to the corresponding smtp_bind_address value.
/etc/postfix/master.cf
smtp_one .. .. .. .. .. .. smtp
-o smtp_bind_address=address-for-one
-o smtp_helo_name=helo-for-one
smtp_two .. .. .. .. .. .. smtp
-o smtp_bind_address=address-for-two
-o smtp_helo_name=helo-for-two
...
Additionally, you may need to reduce process limits in master.cf,
or have {smtp_one,smtp_two,...}_destination_concurrency_limit
settings in main.cf.
Wietse
Re: Reverse smtpd_sender_login_maps
On Wed, Oct 7, 2020 at 2:34 PM Tom Sommer wrote:
>
> So SASL user "t...@example.com" would be able to send only from
> "@example.com".
smtpd_sender_login_maps = pcre:/etc/postfix/login_maps.pcre
content of /etc/postfix/login_maps.pcre:
/^(.*)@your(own)?domain\.org$/ ${1}
This would force sasl-authed user "me" to only send from
m...@yourdomain.org or m...@yourowndomain.org.
You can change the regex to allow from @domain instead.
Reverse smtpd_sender_login_maps
I'm trying to get smtpd_sender_login_maps to allow any sasl-auth'd user to only send from the domain they are logged in as. So SASL user "t...@example.com" would be able to send only from "@example.com". So far I have no luck turning the lookup table into this, is it even possible? Thanks -- Tom
Re: auto smtp_bind_address
Hello Another problem is "Hello" Does anyone have a solution to this IP rotation problem? On 07.10.2020 12:46, natan wrote: > Hi > I thinking about rotate via iptables like > > iptables -t nat -I POSTROUTING -m state --state NEW -p tcp --dport 25 -o > eth0 -m statistic --mode nth --packet 1 --every 2 -j SNAT --to-source IP1 > iptables -t nat -I POSTROUTING -m state --state NEW -p tcp --dport 25 -o > eth0 -m statistic --mode nth --packet 1 --every 2 -j SNAT --to-source IP2 > > I don't know how it will behave if someone has a dedicated IP for > sending mail > > On 07.10.2020 12:10, natan wrote: >> Hello >> I have such a solution: >> >> 1)One serwer to incomming >> 2)One server to outgoing >> >> All Customers in their mail clients (outgoing) use adress: smtp.foobar.org >> >> In main.cf I use smtp_bind_address - for default IP send >> and sender_dependent_default_transport_maps (for indiwydual IP) >> works fine. >> >> Is any change to "auto changing" IP in smtp_bind_address ? >> I know this is a stupid question but I have some problem with throttling >> with send e-mail to *.protection.outlook.com if I change IP in >> smtp_bind_address (RBL, for example) >> >> I think about sharing users and group addresses for sending mail - but >> maybe is simpler solution ? >> -- >> > -- > --
Re: auto smtp_bind_address
Hi I thinking about rotate via iptables like iptables -t nat -I POSTROUTING -m state --state NEW -p tcp --dport 25 -o eth0 -m statistic --mode nth --packet 1 --every 2 -j SNAT --to-source IP1 iptables -t nat -I POSTROUTING -m state --state NEW -p tcp --dport 25 -o eth0 -m statistic --mode nth --packet 1 --every 2 -j SNAT --to-source IP2 I don't know how it will behave if someone has a dedicated IP for sending mail On 07.10.2020 12:10, natan wrote: > Hello > I have such a solution: > > 1)One serwer to incomming > 2)One server to outgoing > > All Customers in their mail clients (outgoing) use adress: smtp.foobar.org > > In main.cf I use smtp_bind_address - for default IP send > and sender_dependent_default_transport_maps (for indiwydual IP) > works fine. > > Is any change to "auto changing" IP in smtp_bind_address ? > I know this is a stupid question but I have some problem with throttling > with send e-mail to *.protection.outlook.com if I change IP in > smtp_bind_address (RBL, for example) > > I think about sharing users and group addresses for sending mail - but > maybe is simpler solution ? > -- > --
auto smtp_bind_address
Hello I have such a solution: 1)One serwer to incomming 2)One server to outgoing All Customers in their mail clients (outgoing) use adress: smtp.foobar.org In main.cf I use smtp_bind_address - for default IP send and sender_dependent_default_transport_maps (for indiwydual IP) works fine. Is any change to "auto changing" IP in smtp_bind_address ? I know this is a stupid question but I have some problem with throttling with send e-mail to *.protection.outlook.com if I change IP in smtp_bind_address (RBL, for example) I think about sharing users and group addresses for sending mail - but maybe is simpler solution ? --
Re: Exception to login_mismatch with IP Whitelisting?
Dnia 6.10.2020 o godz. 18:30:28 Rick King pisze: > > Now our customer has subscribed to Shopify, which apparently sends > messages using the customer's email address as the FROM address. Which > results in a rejection with a 553 5.7.1 Sender address rejected: not > logged in. So I understand you are enforcing authentication (and identity of sender address to SASL username) on INCOMING mail that seems to be from your domain? That's a very bad idea, it breaks forwarding, some mailing lists and many other things. You should enforce authentication only on submission service, not on general incoming mail. -- 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."
