Re: easiest way to reject/process emails based on Return Path
On 07 May 2020, at 19:31, yuv wrote: > I am operating a smallish postfix server for my law office. Many of > our contacts use Google's calendar, and when they enter one of our > email addresses into their calendar entries, we receive a flood of > annoying emails. Invitations / reminders / updates / changes / > cancellations of meetings. This is a “feature” of Google Calendar. > Initially, after receiving twelve emails for a single calendar entry > repeated weekly for three months, I wanted to outright reject the > Google spam. After the second change within 24 hours, I also wanted to > fire the client. But maybe there is smarter way to deal with this > annoyance, such as re-directing the emails to an auto-responder That would be a very bad idea. > or some other form of automated processing (/dev/null comes to my mind too)? Filter them into their own mailbox and auto-mark them as read. > Below is the PCRE that I came up with to catch the offending messages, > without blocking other correspondence (the contacts and their > organizations are likely to use Google's SMTP for their regular > emails): > > /^Return-Path:(.+)(calendar-server.bounces.google.com)(.*)/ REJECT No > Google Calendar Spam Here If you reject mail from Google, Google will stop sending you mail. ALL mail. Can you afford that? > But maybe rewriting the destination address, or sending an auto- > responder right away? I just want to get that spam out of the way in > the most elegant way possible. Sieve/procmail. -- My own people are trying to kill me? It's so French.
Re: explicit shlib_directory in main.cf
On 07.05.2020 20:38, Wietse Venema wrote:
> Maxim Nikulin:
>>
>> Just to avoid any ambiguity, you suggest that package post install
>> script should have something like the following, don't you?
>>
>> postfix upgrade-configuration \
>
> In which script file or documentation file?
>
>> shlib_directory=/usr/lib...
>> ...
>
> Why would one want to hard-code /usr/lib?
In real life some kind parametrization is expected here
(I realized I am unsure concerning postfix, generally /usr/local
is used by default.) I put "/usr/lib..." just avoid diving into
details with e.g. RPM macro expansion or parameters of alternative
build and packaging scripts. Is it OK to discuss Fedora packaging
rules? (RedHat EL .spec file is similar)
https://src.fedoraproject.org/rpms/postfix/raw/master/f/postfix.spec
Post-install RPM script
https://src.fedoraproject.org/rpms/postfix/blob/HEAD/f/postfix.spec#_447
%post -e
contains in particular
https://src.fedoraproject.org/rpms/postfix/blob/HEAD/f/postfix.spec#_451
%{_sbindir}/postfix set-permissions upgrade-configuration \
daemon_directory=%{postfix_daemon_dir} \
# More parameters...
>From your words I decided that the following line should be added here
shlib_directory=%{postfix_shlib_dir} \
I took it from install step
https://src.fedoraproject.org/rpms/postfix/blob/HEAD/f/postfix.spec#_309
%install
namely from "make non-interactive-package" command
https://src.fedoraproject.org/rpms/postfix/blob/HEAD/f/postfix.spec#_322
It uses definition of the internal postfix_shlib_dir parameter
%define postfix_shlib_dir%{_libdir}/postfix
https://src.fedoraproject.org/rpms/postfix/blob/HEAD/f/postfix.spec#_32
> Why not also override queue_directory, data_directory, etc? Of
> course many of these are meaningful only for first-time installs.
Sorry, I narrowed down context too much, My question was on
shlib_directory, so I assumed that "..." is a proper substitution
for all other variables. By the way, I noticed that queue_directory
and data_directory are passed to "make non-interactive-package"
but not to "postfix upgrade-configuration" (and shlib_directory too).
>>> As for shlib_dir in main.cf:
>>>
>>> shlib_dir not only specifies at BUILD time the location for
>>> libpostfix-*, information that the runtime linker needs to use to
>>> start a Postfix program, before any Postfix program can look up
>>> settings in main.cf.
>
> You missed the paragraph that immediately follows this. It explains
> how the main.cf setting is used during RUN time.
Maybe I stick too strong to workflow with installing of prepared
rpm or deb packages as opposite to compiling and installing
from sources. I realized the following might be a reason
to *avoid* default value in the config file inside a package:
>>> and therefore this location may be changed after Postfix is built.
If administrator of particular server installed a package
and later decided to move .so files to other directory
then it is time to add explicit shlib_directory to main.cf.
This case invoking "postfix upgrade-configuration" with
shlib_directory parameter in package post-install script
will break postfix. The script is executed during package
upgrade and such scenario includes the cases of transitions
from one package vendor to another perhaps with change
of package layout. I suspect that in general it should
be quite fragile solution to alternate shlib_directory
while using packages.
So the source of problems is upgrade of package between
versions with different layouts or with/without support
of shared libraries. If shlib_directory were absent in main.cf
and all programs were getting the value from postconf instead of
reading main.cf directly than package upgrades would be smooth.
Such way is not viable since there are installations
with explicit shlib_directory across the world.
So the only way is to force updating the setting to built-in
value from new package version (and no possibility to customize
shlib_directory on particular server if postfix is installed
from a package). Commenting out the line in the post install script
could be an alternative.
To summarize, I am considering adapting of the following to
particular packaging system
# post-install stage (clean install or upgrade)
%{_sbindir}/postfix set-permissions upgrade-configuration \
shlib_directory=%{postfix_shlib_dir} \
daemon_directory=%{postfix_daemon_dir} \
# More parameters...
easiest way to reject/process emails based on Return Path
Hello List: I am operating a smallish postfix server for my law office. Many of our contacts use Google's calendar, and when they enter one of our email addresses into their calendar entries, we receive a flood of annoying emails. Invitations / reminders / updates / changes / cancellations of meetings. Initially, after receiving twelve emails for a single calendar entry repeated weekly for three months, I wanted to outright reject the Google spam. After the second change within 24 hours, I also wanted to fire the client. But maybe there is smarter way to deal with this annoyance, such as re-directing the emails to an auto-responder or some other form of automated processing (/dev/null comes to my mind too)? Below is the PCRE that I came up with to catch the offending messages, without blocking other correspondence (the contacts and their organizations are likely to use Google's SMTP for their regular emails): /^Return-Path:(.+)(calendar-server.bounces.google.com)(.*)/ REJECT No Google Calendar Spam Here where/how do I best add the restriction to Postfix? I was thinking to make it an smtpd_restriction_classes so that I can apply it to some recipients but not to others. But maybe rewriting the destination address, or sending an auto- responder right away? I just want to get that spam out of the way in the most elegant way possible. Thanks in advance for your help, Yuv
Re: hostname in sasl/pam requests
Matus UHLAR - fantomas: I have set up pam_abl to automatically block hosts and users from logging. Unfortunately, the hostname seems not to be visible in pam logs: May 7 17:49:38 mail pam-abl[18692]: Blocking access from (null) to service smtp, user xxx is it possible to pass connecting hostname to pam somehow? On 07.05.20 13:07, Wietse Venema wrote: Is ths Cyrus SASL or dovecot SASL? Postfix passes the client info to Dovecot and Cyrus. On 07.05.20 19:20, Matus UHLAR - fantomas wrote: cyrus 2.1.27, postfix 3.4.8 (debian 10) I will look into it deeper. and there it is: https://github.com/cyrusimap/cyrus-sasl/pull/6 ksmurchison commented on Nov 23, 2016 I think I'd like to hold off on this until a 2.2 release. I don't want to change the wire protocol in a patch version -- Matus UHLAR - fantomas, uh...@fantomas.sk ; http://www.fantomas.sk/ Warning: I wish NOT to receive e-mail advertising to this address. Varovanie: na tuto adresu chcem NEDOSTAVAT akukolvek reklamnu postu. Linux IS user friendly, it's just selective who its friends are...
Re: hostname in sasl/pam requests
Matus UHLAR - fantomas:
I have set up pam_abl to automatically block hosts and users from logging.
Unfortunately, the hostname seems not to be visible in pam logs:
May 7 17:49:38 mail pam-abl[18692]: Blocking access from (null) to service
smtp, user xxx
is it possible to pass connecting hostname to pam somehow?
On 07.05.20 13:07, Wietse Venema wrote:
Is ths Cyrus SASL or dovecot SASL? Postfix passes the client info
to Dovecot and Cyrus.
cyrus 2.1.27, postfix 3.4.8 (debian 10)
I will look into it deeper.
smtpd_sasl_glue.c:
#define ADDR_OR_EMPTY(addr, unknown) (strcmp(addr, unknown) ? addr : "")
#define REALM_OR_NULL(realm) (*(realm) ? (realm) : (char *) 0)
if ((state->sasl_server =
XSASL_SERVER_CREATE(smtpd_sasl_impl, &create_args,
stream = state->client,
addr_family = state->addr_family,
server_addr = ADDR_OR_EMPTY(state->dest_addr,
SERVER_ADDR_UNKNOWN),
server_port = ADDR_OR_EMPTY(state->dest_port,
SERVER_PORT_UNKNOWN),
client_addr = ADDR_OR_EMPTY(state->addr,
CLIENT_ADDR_UNKNOWN),
client_port = ADDR_OR_EMPTY(state->port,
CLIENT_PORT_UNKNOWN),
service = var_smtpd_sasl_service,
user_realm = REALM_OR_NULL(var_smtpd_sasl_realm),
security_options = sasl_opts_val,
tls_flag = tls_flag)) == 0)
msg_fatal("SASL per-connection initialization failed");
xsasl_cyrus_server.c
server_addr_port = (*args->server_addr && *args->server_port ?
concatenate(args->server_addr, ";",
args->server_port, (char *) 0) : 0);
client_addr_port = (*args->client_addr && *args->client_port ?
concatenate(args->client_addr, ";",
args->client_port, (char *) 0) : 0);
...
if ((sasl_status =
SASL_SERVER_NEW(args->service, var_myhostname,
args->user_realm ? args->user_realm : NO_AUTH_REALM,
server_addr_port, client_addr_port,
NO_SESSION_CALLBACKS, NO_SECURITY_LAYERS,
&sasl_conn)) != SASL_OK) {
msg_warn("SASL per-connection server initialization: %s",
xsasl_cyrus_strerror(sasl_status));
XSASL_CYRUS_SERVER_CREATE_ERROR_RETURN(0);
}
xsasl_dovecot_server.c:
server->client_addr = mystrdup(args->client_addr);
vstream_fprintf(server->impl->sasl_stream,
"AUTH\t%u\t%s\tservice=%s\tnologin\tlip=%s\trip=%s",
server->last_request_id, sasl_method,
server->service, server->server_addr,
server->client_addr);
--
Matus UHLAR - fantomas, uh...@fantomas.sk ; http://www.fantomas.sk/
Warning: I wish NOT to receive e-mail advertising to this address.
Varovanie: na tuto adresu chcem NEDOSTAVAT akukolvek reklamnu postu.
Despite the cost of living, have you noticed how popular it remains?
Re: hostname in sasl/pam requests
Matus UHLAR - fantomas:
> Hello,
>
> I have set up pam_abl to automatically block hosts and users from logging.
> Unfortunately, the hostname seems not to be visible in pam logs:
>
> May 7 17:49:38 mail pam-abl[18692]: Blocking access from (null) to service
> smtp, user xxx
>
> is it possible to pass connecting hostname to pam somehow?
Is ths Cyrus SASL or dovecot SASL? Postfix passes the client info
to Dovecot and Cyrus.
Wietse
smtpd_sasl_glue.c:
#define ADDR_OR_EMPTY(addr, unknown) (strcmp(addr, unknown) ? addr : "")
#define REALM_OR_NULL(realm) (*(realm) ? (realm) : (char *) 0)
if ((state->sasl_server =
XSASL_SERVER_CREATE(smtpd_sasl_impl, &create_args,
stream = state->client,
addr_family = state->addr_family,
server_addr = ADDR_OR_EMPTY(state->dest_addr,
SERVER_ADDR_UNKNOWN),
server_port = ADDR_OR_EMPTY(state->dest_port,
SERVER_PORT_UNKNOWN),
client_addr = ADDR_OR_EMPTY(state->addr,
CLIENT_ADDR_UNKNOWN),
client_port = ADDR_OR_EMPTY(state->port,
CLIENT_PORT_UNKNOWN),
service = var_smtpd_sasl_service,
user_realm = REALM_OR_NULL(var_smtpd_sasl_realm),
security_options = sasl_opts_val,
tls_flag = tls_flag)) == 0)
msg_fatal("SASL per-connection initialization failed");
xsasl_cyrus_server.c
server_addr_port = (*args->server_addr && *args->server_port ?
concatenate(args->server_addr, ";",
args->server_port, (char *) 0) : 0);
client_addr_port = (*args->client_addr && *args->client_port ?
concatenate(args->client_addr, ";",
args->client_port, (char *) 0) : 0);
...
if ((sasl_status =
SASL_SERVER_NEW(args->service, var_myhostname,
args->user_realm ? args->user_realm : NO_AUTH_REALM,
server_addr_port, client_addr_port,
NO_SESSION_CALLBACKS, NO_SECURITY_LAYERS,
&sasl_conn)) != SASL_OK) {
msg_warn("SASL per-connection server initialization: %s",
xsasl_cyrus_strerror(sasl_status));
XSASL_CYRUS_SERVER_CREATE_ERROR_RETURN(0);
}
xsasl_dovecot_server.c:
server->client_addr = mystrdup(args->client_addr);
vstream_fprintf(server->impl->sasl_stream,
"AUTH\t%u\t%s\tservice=%s\tnologin\tlip=%s\trip=%s",
server->last_request_id, sasl_method,
server->service, server->server_addr,
server->client_addr);
hostname in sasl/pam requests
Hello, I have set up pam_abl to automatically block hosts and users from logging. Unfortunately, the hostname seems not to be visible in pam logs: May 7 17:49:38 mail pam-abl[18692]: Blocking access from (null) to service smtp, user xxx is it possible to pass connecting hostname to pam somehow? (I would like to block hosts as well as users when possible) -- Matus UHLAR - fantomas, uh...@fantomas.sk ; http://www.fantomas.sk/ Warning: I wish NOT to receive e-mail advertising to this address. Varovanie: na tuto adresu chcem NEDOSTAVAT akukolvek reklamnu postu. I just got lost in thought. It was unfamiliar territory.
Re: Illegal address syntax
On Wed, May 06, 2020 at 11:51:37PM +, Pedro David Marco wrote: > Hi! > Is it possible to make Postfix Reject instead of warn for "Illegal > address syntax"? To avoid flooding logs with garbage, Postfix normally REJECTs command syntax errors without logging anything. However, there is a long history of clients that send invalid address syntax to Postfix and that fail to report Postfix REJECTs to the user. Such cases would be impossible to debug without some logging. Wietse
Re: explicit shlib_directory in main.cf
Maxim Nikulin: > Wietse Venema: > > Maxim Nikulin: > >> > >> I have noticed than postfix-install script explicitly adds > >> shlib_directory to the main.cf file e.g. during non-interactive install. > > > > Postfix records all installation settings in main.cf even if they > > are at their built-in defaults. That is because defaults change > > over time, and I don't want things to break when people upgrade to > > a newer release. Thank you for not blowing away existing config > > files. You're expected to run "postfix upgrade-configuration" > > instead. > > Just to avoid any ambiguity, you suggest that package post install > script should have something like the following, don't you? > > postfix upgrade-configuration \ In which script file or documentation file? > shlib_directory=/usr/lib... > ... Why would one want to hard-code /usr/lib? Why not also override queue_directory, data_directory, etc? Of course many of these are meaningful only for first-time installs. > > As for shlib_dir in main.cf: > > > > shlib_dir not only specifies at BUILD time the location for > > libpostfix-*, information that the runtime linker needs to use to > > start a Postfix program, before any Postfix program can look up > > settings in main.cf. You missed the paragraph that immediately follows this. It explains how the main.cf setting is used during RUN time. > I feel come confusion here. postconf -d shlib_directory reports > expected build-time value. Do you mean components that reads > main.cf directly instead of query to postconf? Presence or absence > of explicit shlib_directory in main.cf does not help in the case > of problem with library load paths. Wietse
Re: Illegal address syntax
On Wed, May 06, 2020 at 11:51:37PM +, Pedro David Marco wrote: > Hi! > Is it possible to make Postfix Reject instead of warn for "Illegal address > syntax"? So I've actually mailed about the same issue last week. As far as I can see, postfix does reject it. My case was with a space in the username. If I test this with Thunderbird, I don't the warning, I get a proper error that the user doesn't exist. The client that caused that warning was using Outlook. I've not yet been able to do test with Outlook. But from the tests I did do, it seems that Outlook just ignores the error that postfix returns. Kurt
Re: explicit shlib_directory in main.cf
Wietse Venema: > Maxim Nikulin: >> >> I have noticed than postfix-install script explicitly adds >> shlib_directory to the main.cf file e.g. during non-interactive install. > > Postfix records all installation settings in main.cf even if they > are at their built-in defaults. That is because defaults change > over time, and I don't want things to break when people upgrade to > a newer release. Thank you for not blowing away existing config > files. You're expected to run "postfix upgrade-configuration" > instead. Just to avoid any ambiguity, you suggest that package post install script should have something like the following, don't you? postfix upgrade-configuration \ ... shlib_directory=/usr/lib... ... That sounds reasonable. RedHat package contains a call to upgrade-configuration however without shlib_directory, in Debian package I have not noticed it at all. Concerning changed defaults, I expect that package manager should ensure through dependencies and conflicts that consistent set of files is present in the system and actual location files is the same as built-in values. Vice versa I faced an upgrade problem with diverged explicit value in config and real paths in new packages. But you are right, it happened due to absence of proper upgrade-configuration call. > As for shlib_dir in main.cf: > > shlib_dir not only specifies at BUILD time the location for > libpostfix-*, information that the runtime linker needs to use to > start a Postfix program, before any Postfix program can look up > settings in main.cf. I feel come confusion here. postconf -d shlib_directory reports expected build-time value. Do you mean components that reads main.cf directly instead of query to postconf? Presence or absence of explicit shlib_directory in main.cf does not help in the case of problem with library load paths. > You mention the PORTING document. It likely needs updating, as it > was last updated in 2004, about 10 years before I adopted support > for dynamic linking in Postfix 3.0. Are you using "PORTING" as a nickname for "Guidelines for Package Builders"? PACKAGE_README file has modification time in 2015, do not know if it was a significant update. Thank you for the valuable hint, "postfix upgrade-configuration" is almost certainly what I am looking for.
Re: Illegal address syntax
On 06.05.20 23:51, Pedro David Marco wrote: Hi! Is it possible to make Postfix Reject instead of warn for "Illegal address syntax"? Thanks! doesn't it reject? I have rejections here although log says warn: May 7 08:22:43 mail postfix/smtps/smtpd[653]: connect from unknown[192.168.x.x] May 7 08:22:44 mail postfix/smtps/smtpd[653]: warning: Illegal address syntax from unknown[192.168.x.x] in RCPT command: May 7 08:22:47 mail postfix/smtps/smtpd[653]: disconnect from unknown[192.168.x.x] ehlo=1 auth=1 mail=1 rcpt=0/1 quit=1 commands=4/5 -- Matus UHLAR - fantomas, uh...@fantomas.sk ; http://www.fantomas.sk/ Warning: I wish NOT to receive e-mail advertising to this address. Varovanie: na tuto adresu chcem NEDOSTAVAT akukolvek reklamnu postu. Enter any 12-digit prime number to continue.
null recipient "@example.com"@example.com accepted
Hello, I ust received mail where user specified destination address: @example@example.com the mail was accepted and forwarded to "empty_address_recipient", which docs' say: "...Postfix does not accept such addresses in SMTP commands..." http://www.postfix.org/postconf.5.html#empty_address_recipient however, the address is accepted from remote sites, when I enter destination domain this way. Even newer postfix versions (3.4.8 checked) accept it. Should such destination addresses be accepted? postfix 2.11.3, Debian 8 smtpd_recipient_restrictions = reject_non_fqdn_recipient, reject_unknown_recipient_domain, permit_mynetworks, permit_sasl_authenticated, reject_unauth_destination, -- Matus UHLAR - fantomas, uh...@fantomas.sk ; http://www.fantomas.sk/ Warning: I wish NOT to receive e-mail advertising to this address. Varovanie: na tuto adresu chcem NEDOSTAVAT akukolvek reklamnu postu. Boost your system's speed by 500% - DEL C:\WINDOWS\*.*
