Re: strange issue with postfix
On 05 Oct 2020, at 13:17, Bob Proulx wrote: > Here is an old resource but one that I think is still very good is > "Jim Seymour's suggestions/examples for Postfix anti-UCE configuration." > >http://jimsun.linxnet.com/misc/postfix-anti-UCE.txt It's good, but it does need some updating as some things are… misleading. For example: If you want smtpd access map entries to match hosts and sub-domains on just the domain part (e.g.: "example.com" matches "host.example.com" and "host.subdomain.example.com," you must specify: parent_domain_matches_subdomains = smtpd_access_maps However, that is the default: # postconf -d parent_domain_matches_subdomains parent_domain_matches_subdomains = debug_peer_list,fast_flush_domains,mynetworks,permit_mx_backup_networks,qmqpd_authorized_clients,relay_domains,smtpd_access_maps There's the whole section on postfix not supporting cidr tables, which was certainly possible in 2005, but not so much in 2020. But yes, it's still a good starter document for understanding the configuration parameters and the order-of-operations flow, but I wouldn't rely on it to generate you own config without checking some of the `postconf -n` output that gets posted to the list. The one thing that it tries very hard to do is explain the meaning of the sender and recipient maps and while everything there is correct, I think it would still be quite confusing to someone starting off with postfix who is likely to wonder if it means that senders are always local or is senders are never local or if sender might be local and might be not local, which I think is the single biggest stumbling block for those undertaking modifying their postfix configs. Pr maybe it's smtp_ versus smtpd_, a mistake that is in the post: The "general flow" of the smtp_recipient_restrictions … But only smtpd_recipient_restrictions are in the file. But, the biggest thing that makes this document in real need of an update, is the complete lack of mention of postfix's best antispam feature: postscreen. -- Bart, don't use the Touch of Death on your sister.
Re: Accessing the sending user from a canonical(5) table
On 10/5/20 6:15 PM, Wietse Venema wrote:
Demi M. Obenour:
There was a recent vulnerability in OpenBSD due to libc malfunctioning
in a set-uid-root program under very low resource limits. I would
prefer to minimize the amount of third-party libraries that are used
by postdrop. That said, another option would be to error out if the
resource limits are below what we consider a reasonable minimum.
Another good reason for not using set-uid root programs...
Indeed.
I don't think it is practical for Postfix to have universal minimal
resource limts. You can add some custom OPENBSD code later.
That makes sense. The OpenBSD vulnerability has been fixed, and was
merely used as an example. No OpenBSD-specific code will be needed,
at least not for this purpose.
Surprise: Postfix has a strip_addr() function that can remove adress
extensions before enforcing the ACL.
Good to know! That proved critical.
Is the code in smtpd_check.c a good place to start?
Yes. It also helps you to become familiar with Postfix's
approach to parsing.
Indeed it was helpful. Thanks for the tip!
Patch (made against 3.5.7) attached. I lightly tested it locally and
it seems to work, but there could very well be bugs. I am virtually
certain that I violated the Postfix coding style somewhere, sorry.
I can also send the patch inline if you prefer.
For what it is worth, I found the Postfix source code to be very clean
and easy to read. Writing this patch probably took about four hours
of work, which is significantly less than I expected for a non-trivial
feature. Thank you for all the work you have put into Postfix!
Wietse
Thank you,
Demi
diff -ur postfix-3.5.7-old/src/global/mail_params.h postfix-3.5.7/src/global/mail_params.h
--- postfix-3.5.7-old/src/global/mail_params.h 2020-05-09 11:51:27.0 -0400
+++ postfix-3.5.7/src/global/mail_params.h 2020-10-05 18:10:32.64100 -0400
@@ -1667,6 +1667,10 @@
#define DEF_SMTPD_SASL_TYPE DEF_SERVER_SASL_TYPE
extern char *var_smtpd_sasl_type;
+#define VAR_LOCAL_SND_AUTH_MAPS "local_sender_login_maps"
+#define DEF_LOCAL_SND_AUTH_MAPS "static:*"
+extern char *var_local_snd_auth_maps;
+
#define VAR_SMTPD_SND_AUTH_MAPS "smtpd_sender_login_maps"
#define DEF_SMTPD_SND_AUTH_MAPS ""
extern char *var_smtpd_snd_auth_maps;
diff -ur postfix-3.5.7-old/src/postdrop/postdrop.c postfix-3.5.7/src/postdrop/postdrop.c
--- postfix-3.5.7-old/src/postdrop/postdrop.c 2019-10-13 11:32:18.0 -0400
+++ postfix-3.5.7/src/postdrop/postdrop.c 2020-10-05 18:48:02.07800 -0400
@@ -147,6 +147,10 @@
#include
#include
#include
+#include
+#include
+#include
+#include
/* Application-specific. */
@@ -167,9 +171,10 @@
* Local mail submission access list.
*/
char *var_submit_acl;
-
+char *var_local_snd_auth_maps;
static const CONFIG_STR_TABLE str_table[] = {
VAR_SUBMIT_ACL, DEF_SUBMIT_ACL, _submit_acl, 0, 0,
+VAR_LOCAL_SND_AUTH_MAPS, DEF_LOCAL_SND_AUTH_MAPS, _local_snd_auth_maps, 0, 0,
0,
};
@@ -231,6 +236,7 @@
int c;
VSTRING *buf;
int status;
+MAPS*local_sender_login_maps;
MAIL_STREAM *dst;
int rec_type;
static char *segment_info[] = {
@@ -239,6 +245,7 @@
char **expected;
uid_t uid = getuid();
ARGV *import_env;
+struct mypasswd *username;
const char *error_text;
char *attr_name;
char *attr_value;
@@ -316,16 +323,6 @@
get_mail_conf_str_table(str_table);
/*
- * Mail submission access control. Should this be in the user-land gate,
- * or in the daemon process?
- */
-mail_dict_init();
-if ((errstr = check_user_acl_byuid(VAR_SUBMIT_ACL, var_submit_acl,
- uid)) != 0)
- msg_fatal("User %s(%ld) is not allowed to submit mail",
- errstr, (long) uid);
-
-/*
* Stop run-away process accidents by limiting the queue file size. This
* is not a defense against DOS attack.
*/
@@ -369,11 +366,34 @@
/* End of initializations. */
/*
+ * Mail submission access control. Should this be in the user-land gate,
+ * or in the daemon process?
+ */
+mail_dict_init();
+if ((errstr = check_user_acl_byuid(VAR_SUBMIT_ACL, var_submit_acl,
+ uid)) != 0)
+ msg_fatal("User %s(%ld) is not allowed to submit mail",
+ errstr, (long) uid);
+
+local_sender_login_maps = maps_create(VAR_SMTPD_SND_AUTH_MAPS,
+ var_local_snd_auth_maps,
+ DICT_FLAG_FOLD_FIX |
+ DICT_FLAG_UTF8_REQUEST |
+ DICT_FLAG_NO_PROXY |
+ DICT_FLAG_NO_UNAUTH);
+
+/*
* Don't trust the caller's time information.
*/
GETTIMEOFDAY();
/*
+ * Get the username.
+ */
+if ((username = mypwuid(uid)) == NULL)
+ msg_fatal("Cannot get username for uid %ld", (long) uid);
+
+/*
* Create queue file. mail_stream_file() never fails. Send the queue ID
* to the caller. Stash away a copy of the queue file name so we can
* clean up in case
Re: Accessing the sending user from a canonical(5) table
Demi M. Obenour: > There was a recent vulnerability in OpenBSD due to libc malfunctioning > in a set-uid-root program under very low resource limits. I would > prefer to minimize the amount of third-party libraries that are used > by postdrop. That said, another option would be to error out if the > resource limits are below what we consider a reasonable minimum. Another good reason for not using set-uid root programs... I don't think it is practical for Postfix to have universal minimal resource limts. You can add some custom OPENBSD code later. > > If you are thinking of skipping the Postfix dictionary API and > > crafting your own table lookups, then that is definiitely > > not going to happen. > > Indeed that would be a bad idea. > > >> What about allowing everyone to send mail as themselves, and having > >> a list of users who can send mail as anyone? That is what Sendmail > >> provides. If a delimiter is specified in the configuration, it would > >> be honored. > > > > By default, a user can send mail as everyone, and that default > > behavior cannot be changed. So the question becomes: what is the > > behavior? I think it should behave like smtp_sender_login_maps, > > because there is no reason to invent new behavior. > > Agreed. This also lets us use common code for both ACLs. > > > This means the search string is the UNIX username, and the lookup > > result is a comma-separated list of things (usernames and/or email > > addresses) that they may specify as the envelope sender address. > > > > Your 'identity' mapping then looks like this: > > > > /etc/postfix/main.cf: > > local_sender_login_maps = > > pcre:/etc/postfix/local_sender_logins > > > > /etc/postfix/local_sender_logins > > /(.+)/ $1, $1...@example.com > > > > I.e. a user can send mail only if the envelope sender equals their > > login name, or usern...@example.com. There will need to be a wildcard > > pattern that allows all, as would be needed by a content filter > > that re-injects mail using the Postfix sendmail command. > > That looks good. I do wish there was a way (other than allow > all) to express that Alice can send mail as al...@example.com, > alice+t...@example.com, alice+te...@example.com, etc. I might just > not know of such a method, however, and in any case that is not > related to the current project. Surprise: Postfix has a strip_addr() function that can remove adress extensions before enforcing the ACL. > Is the code in smtpd_check.c a good place to start? Yes. It also helps you to become familiar with Postfix's approach to parsing. Wietse
Re: postscreen seqfaults with abusix rbl
John Fawcett:
> Actually to be more precise: is it guaranteed to return not null and
> with all the function pointers in the returned dict struct also not
> null. I'm adding this because I think it does always return something
> not null, but I'm not sure that the function pointers are always not
> null. There's a condition that sometimes does not define update and
> delete in dict_surrogate.c
>
> ?? if (open_flags & O_RDWR) {
> ??? dp->dict.update = dict_surrogate_update;
> ??? dp->dict.delete = dict_surrogate_delete;
> ??? }
>
> Not sure if that helps, but just an idea.
Those function pointer are initialized by dict_alloc() as pointers
to function that say "you cannot do this".
Wietse
Re: postscreen seqfaults with abusix rbl
On 05/10/2020 23:18, John Fawcett wrote:
> On 05/10/2020 22:19, Wietse Venema wrote:
>> Benny Pedersen:
>>> Oct 5 17:01:09 localhost kernel: postscreen[387]: segfault at 0 ip
>>> 7f78d9773cea sp 7ffeb1cb0960 error 4 in
>>> libpostfix-util.so[7f78d9759000+29000]
>>> Oct 5 17:09:51 localhost kernel: postscreen[1310]: segfault at 0 ip
>>> 7f372355dcea sp 7fff7569b520 error 4 in
>>> libpostfix-util.so[7f3723543000+29000]
>>> Oct 5 17:18:20 localhost kernel: postscreen[11822]: segfault at 0 ip
>>> 7f4a3e9bfcea sp 7ffea70b09c0 error 4 in
>>> libpostfix-util.so[7f4a3e9a5000+29000]
>>> Oct 5 17:19:57 localhost kernel: postscreen[20595]: segfault at 0 ip
>>> 7fe15ba10cea sp 7ffc68250090 error 4 in
>>> libpostfix-util.so[7fe15b9f6000+29000]
>>> Oct 5 17:21:38 localhost kernel: postscreen[11930]: segfault at 0 ip
>>> 7fdf1de1fcea sp 7dfc02c0 error 4 in
>>> libpostfix-util.so[7fdf1de05000+29000]
>>> Oct 5 17:22:14 localhost kernel: postscreen[16126]: segfault at 0 ip
>>> 7f69bc4ddcea sp 7ffeab170220 error 4 in
>>> libpostfix-util.so[7f69bc4c3000+29000]
>>> Oct 5 17:22:20 localhost kernel: postscreen[16138]: segfault at 0 ip
>>> 7f7c9db76cea sp 7ffc3e818b70 error 4 in
>>> libpostfix-util.so[7f7c9db5c000+29000]
>>> Oct 5 17:27:18 localhost kernel: postscreen[22685]: segfault at 0 ip
>>> 7f027d5a8cea sp 7ffc70a1b5f0 error 4 in
>>> libpostfix-util.so[7f027d58e000+29000]
>>> Oct 5 17:28:36 localhost kernel: postscreen[22746]: segfault at 0 ip
>>> 7fd00d9f2cea sp 7fffb5133e70 error 4 in
>>> libpostfix-util.so[7fd00d9d8000+29000]
>>> Oct 5 17:28:36 localhost kernel: postscreen[22752]: segfault at 0 ip
>>> 7f15ed50ecea sp 7fff054e0ea0 error 4 in
>>> libpostfix-util.so[7f15ed4f4000+29000]
>>> Oct 5 17:29:10 localhost kernel: postscreen[22764]: segfault at 0 ip
>>> 7fbcf74becea sp 7ffc1c2a6840 error 4 in
>>> libpostfix-util.so[7fbcf74a4000+29000]
>>> Oct 5 17:29:16 localhost kernel: postscreen[22767]: segfault at 0 ip
>>> 7f2c802b1cea sp 7ffd9c3d28f0 error 4 in
>>> libpostfix-util.so[7f2c80297000+29000]
>>> Oct 5 17:30:02 localhost kernel: postscreen[22771]: segfault at 0 ip
>>> 7f388bc98cea sp 7ffc372ca850 error 4 in
>>> libpostfix-util.so[7f388bc7e000+29000]
>>>
>>> both with postfix 3.5.6 and 3.5.7 on gentoo
>>>
>>> removed:
>>>
>>> postscreen_dnsbl_reply_map =
>>> texthash:/etc/postfix/postscreen_dnsbl_reply_map
>>> postscreen_dnsbl_sites = APIKEY.combined.mail.abusix.zone
>>>
>>> that removed the seqfaults
>>>
>>> kernel is 5.4.66, dont know if thats related to my problem, is other
>>> seen that problem ?
>> Support for postscreen_dnsbl_* not changed in years. You can try
>> to attack a debugger as in http://www.postfix.org/DEBUG_README.html,
>> to find out what function(s) are active at the time.
>>
>> Wietse
> Hi
>
> maybe just a wild guess... but looking at the code in dict_thash.c is
> this guaranteed to return something not null?
>
> dict = dict_open3(DICT_TYPE_HT, path, open_flags, dict_flags);
>
> If it ever returns null, it would likely produce a segfault later on.
>
> John
>
Actually to be more precise: is it guaranteed to return not null and
with all the function pointers in the returned dict struct also not
null. I'm adding this because I think it does always return something
not null, but I'm not sure that the function pointers are always not
null. There's a condition that sometimes does not define update and
delete in dict_surrogate.c
if (open_flags & O_RDWR) {
dp->dict.update = dict_surrogate_update;
dp->dict.delete = dict_surrogate_delete;
}
Not sure if that helps, but just an idea.
John
John
Re: postscreen seqfaults with abusix rbl
John Fawcett: > >> Oct 5 17:30:02 localhost kernel: postscreen[22771]: segfault at 0 ip > >> 7f388bc98cea sp 7ffc372ca850 error 4 in > >> libpostfix-util.so[7f388bc7e000+29000] > >> > >> both with postfix 3.5.6 and 3.5.7 on gentoo > >> > >> removed: > >> > >> postscreen_dnsbl_reply_map = > >> texthash:/etc/postfix/postscreen_dnsbl_reply_map > >> postscreen_dnsbl_sites = APIKEY.combined.mail.abusix.zone > >> > >> that removed the seqfaults > >> > >> kernel is 5.4.66, dont know if thats related to my problem, is other > >> seen that problem ? > > Support for postscreen_dnsbl_* not changed in years. You can try > > to attack a debugger as in http://www.postfix.org/DEBUG_README.html, > > to find out what function(s) are active at the time. > > > > Wietse > > Hi > > maybe just a wild guess... but looking at the code in dict_thash.c is > this guaranteed to return something not null? > > ??? dict = dict_open3(DICT_TYPE_HT, path, open_flags, dict_flags); > > If it ever returns null, it would likely produce a segfault later on. dict_open never returns null. In case of error, a dictionary terminates with a fatal error, or it returns a "surrogate" dictionary that returns errors for all requests. Wietse
Re: postscreen seqfaults with abusix rbl
On 05/10/2020 22:19, Wietse Venema wrote: > Benny Pedersen: >> Oct 5 17:01:09 localhost kernel: postscreen[387]: segfault at 0 ip >> 7f78d9773cea sp 7ffeb1cb0960 error 4 in >> libpostfix-util.so[7f78d9759000+29000] >> Oct 5 17:09:51 localhost kernel: postscreen[1310]: segfault at 0 ip >> 7f372355dcea sp 7fff7569b520 error 4 in >> libpostfix-util.so[7f3723543000+29000] >> Oct 5 17:18:20 localhost kernel: postscreen[11822]: segfault at 0 ip >> 7f4a3e9bfcea sp 7ffea70b09c0 error 4 in >> libpostfix-util.so[7f4a3e9a5000+29000] >> Oct 5 17:19:57 localhost kernel: postscreen[20595]: segfault at 0 ip >> 7fe15ba10cea sp 7ffc68250090 error 4 in >> libpostfix-util.so[7fe15b9f6000+29000] >> Oct 5 17:21:38 localhost kernel: postscreen[11930]: segfault at 0 ip >> 7fdf1de1fcea sp 7dfc02c0 error 4 in >> libpostfix-util.so[7fdf1de05000+29000] >> Oct 5 17:22:14 localhost kernel: postscreen[16126]: segfault at 0 ip >> 7f69bc4ddcea sp 7ffeab170220 error 4 in >> libpostfix-util.so[7f69bc4c3000+29000] >> Oct 5 17:22:20 localhost kernel: postscreen[16138]: segfault at 0 ip >> 7f7c9db76cea sp 7ffc3e818b70 error 4 in >> libpostfix-util.so[7f7c9db5c000+29000] >> Oct 5 17:27:18 localhost kernel: postscreen[22685]: segfault at 0 ip >> 7f027d5a8cea sp 7ffc70a1b5f0 error 4 in >> libpostfix-util.so[7f027d58e000+29000] >> Oct 5 17:28:36 localhost kernel: postscreen[22746]: segfault at 0 ip >> 7fd00d9f2cea sp 7fffb5133e70 error 4 in >> libpostfix-util.so[7fd00d9d8000+29000] >> Oct 5 17:28:36 localhost kernel: postscreen[22752]: segfault at 0 ip >> 7f15ed50ecea sp 7fff054e0ea0 error 4 in >> libpostfix-util.so[7f15ed4f4000+29000] >> Oct 5 17:29:10 localhost kernel: postscreen[22764]: segfault at 0 ip >> 7fbcf74becea sp 7ffc1c2a6840 error 4 in >> libpostfix-util.so[7fbcf74a4000+29000] >> Oct 5 17:29:16 localhost kernel: postscreen[22767]: segfault at 0 ip >> 7f2c802b1cea sp 7ffd9c3d28f0 error 4 in >> libpostfix-util.so[7f2c80297000+29000] >> Oct 5 17:30:02 localhost kernel: postscreen[22771]: segfault at 0 ip >> 7f388bc98cea sp 7ffc372ca850 error 4 in >> libpostfix-util.so[7f388bc7e000+29000] >> >> both with postfix 3.5.6 and 3.5.7 on gentoo >> >> removed: >> >> postscreen_dnsbl_reply_map = >> texthash:/etc/postfix/postscreen_dnsbl_reply_map >> postscreen_dnsbl_sites = APIKEY.combined.mail.abusix.zone >> >> that removed the seqfaults >> >> kernel is 5.4.66, dont know if thats related to my problem, is other >> seen that problem ? > Support for postscreen_dnsbl_* not changed in years. You can try > to attack a debugger as in http://www.postfix.org/DEBUG_README.html, > to find out what function(s) are active at the time. > > Wietse Hi maybe just a wild guess... but looking at the code in dict_thash.c is this guaranteed to return something not null? dict = dict_open3(DICT_TYPE_HT, path, open_flags, dict_flags); If it ever returns null, it would likely produce a segfault later on. John
Accessing the sending user from a canonical(5) table
On 10/5/20 10:51 AM, Wietse Venema wrote: Demi M. Obenour: On 2020-10-04 19:55, Wietse Venema wrote: Demi M. Obenour: Checking application/pgp-signature: FAILURE -- Start of PGP signed section. On 2020-09-30 16:35, Wietse Venema wrote: Demi M. Obenour: - If a message arrives via the SMTPS or submission ports, I want to replace the address part of the user-supplied From: header with the envelope From: header. This allows me to use reject-sender-login-mismatch to prevent users from sending messages with forged From: addresses. There are two parts to this: 1) Locking down the envelope.from. With authenticated smtp submission, the envelope.from can be constrained by smtpd_sender_login_maps. With sendmail/postdrop submission the UNIX login name can be overidden with "sendmail -f". There is no code in Postfix to lock down "sendmail -f", and there is no 'plugin' interface that could do this, either. I don't like the idea of adding complex logic to the set-gid postdrop command to lock down "sendmail -f". Doing the lockdown in the pickup daemon would be more secure but has the problem that the 'reject' happens too late. I looked at the postdrop source code to see what locking down "sendmail -f" would entail. Checking that the current user can use `-f` seems to be just looking up the current username in an ACL, which postdrop already does for authorized_submit_users. Checking that -f was not passed looks to just be a string equality check, unless I am missing something. Of course, converting the same UID to a username three times is not a good idea performance-wise, but that can be fixed with some minor refactoring. Another option is to emit a good error message from sendmail, and then do the security check in pickup. If a user calls postdrop directly, the reject will happen late, but my understanding is that this isn't supported. Would you be interested in a patch that implemented either of these options? I think that the envelope.from lockdown should be enforced in pickup or before pickup but not both. If it is both then the code in the pickup daemon will be a NOOP. WHen code is usually a NOOP no-one will notice when they break it. If a sender_login_maps feature can be implemented in postdrop without giving an untrusted user control over the programn, then let's try that. I would be willing to try, but I suggest we only support ?simple? maps here. Postfix supports a wide variety of map types, and I would rather not expose that much attack surface in postdrop. Furthermore, in all of the use cases I can think of, a simple policy is fine. I have no idea what that means. Postfix has a separation between lookup mechanisms (hash, pcre) and table-driven mechanisms (access maps, smtp_sender_login_maps). There was a recent vulnerability in OpenBSD due to libc malfunctioning in a set-uid-root program under very low resource limits. I would prefer to minimize the amount of third-party libraries that are used by postdrop. That said, another option would be to error out if the resource limits are below what we consider a reasonable minimum. If you are thinking of skipping the Postfix dictionary API and crafting your own table lookups, then that is definiitely not going to happen. Indeed that would be a bad idea. What about allowing everyone to send mail as themselves, and having a list of users who can send mail as anyone? That is what Sendmail provides. If a delimiter is specified in the configuration, it would be honored. By default, a user can send mail as everyone, and that default behavior cannot be changed. So the question becomes: what is the behavior? I think it should behave like smtp_sender_login_maps, because there is no reason to invent new behavior. Agreed. This also lets us use common code for both ACLs. This means the search string is the UNIX username, and the lookup result is a comma-separated list of things (usernames and/or email addresses) that they may specify as the envelope sender address. Your 'identity' mapping then looks like this: /etc/postfix/main.cf: local_sender_login_maps = pcre:/etc/postfix/local_sender_logins /etc/postfix/local_sender_logins /(.+)/ $1, $1...@example.com I.e. a user can send mail only if the envelope sender equals their login name, or usern...@example.com. There will need to be a wildcard pattern that allows all, as would be needed by a content filter that re-injects mail using the Postfix sendmail command. That looks good. I do wish there was a way (other than allow all) to express that Alice can send mail as al...@example.com, alice+t...@example.com, alice+te...@example.com, etc. I might just not know of such a method, however, and in any case that is not related to the current project. Is the code in smtpd_check.c a good place to start? We just need to make sure that maps are opened after postdrop has stripped the environment, set up signal handlers,
Fwd: Redirection using a 1:1 & domain wildcard alias
I found my answer - RFC-2821 - - - Forwarded message: From: Antonio Leding To: Jaroslaw Rafa Cc: postfix-users@postfix.org Subject: Re: Redirection using a 1:1 & domain wildcard alias Date: Mon, 5 Oct 2020 20:38:00 + Thanks Jaroslaw, Is any of this documented anywhere? I’ve read virtual(5), virtual(8), cleanup(8), etc. ad nowhere in the observed behavior documented. There’s discussion as to order to table searching and address matching but nothing that I’ve seen discusses what happens when there is both a user account and an alias configured nor when a user account and a domain wildcard alias are configured concurrently. If this is all “just understood to be true”, then fine…but if so, would be far better to document this stuff… On the flip side, if I’ve simply missed it, fair enough…just would like to know where… - - - On 5 Oct 2020, at 12:34, Jaroslaw Rafa wrote: Dnia 5.10.2020 o godz. 17:28:04 Antonio Leding pisze: * When both a 1:1 alias & a user are configured for a given email address, why are emails sent to the alias\user only delivered to the alias target? Because that's exactly what aliases are meant for - to deliver mail to the alias target *instead* of the original address. If you want the mail to be delivered *both* to alias target and to the original address, you must alias the original address to a *list* of both these addresses (I don't know if it works for virtual_alias_maps, it certainly works for aliases defined in /etc/aliases) * When a domain wildcard alias & a user are configured, why are emails sent to the user only delivered to the user and no copy to the alias target? Because domain wildcard alias applies *by definition* for any address in the domain that *does not have* it's own alias defined. Once an address has it's own alias defined, wildcard alias is ignored. -- 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."
Re: Redirection using a 1:1 & domain wildcard alias
Thanks Jaroslaw, Is any of this documented anywhere? I’ve read virtual(5), virtual(8), cleanup(8), etc. ad nowhere in the observed behavior documented. There’s discussion as to order to table searching and address matching but nothing that I’ve seen discusses what happens when there is both a user account and an alias configured nor when a user account and a domain wildcard alias are configured concurrently. If this is all “just understood to be true”, then fine…but if so, would be far better to document this stuff… On the flip side, if I’ve simply missed it, fair enough…just would like to know where… - - - On 5 Oct 2020, at 12:34, Jaroslaw Rafa wrote: Dnia 5.10.2020 o godz. 17:28:04 Antonio Leding pisze: * When both a 1:1 alias & a user are configured for a given email address, why are emails sent to the alias\user only delivered to the alias target? Because that's exactly what aliases are meant for - to deliver mail to the alias target *instead* of the original address. If you want the mail to be delivered *both* to alias target and to the original address, you must alias the original address to a *list* of both these addresses (I don't know if it works for virtual_alias_maps, it certainly works for aliases defined in /etc/aliases) * When a domain wildcard alias & a user are configured, why are emails sent to the user only delivered to the user and no copy to the alias target? Because domain wildcard alias applies *by definition* for any address in the domain that *does not have* it's own alias defined. Once an address has it's own alias defined, wildcard alias is ignored. -- 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."
Re: postscreen seqfaults with abusix rbl
Benny Pedersen: > Oct 5 17:01:09 localhost kernel: postscreen[387]: segfault at 0 ip > 7f78d9773cea sp 7ffeb1cb0960 error 4 in > libpostfix-util.so[7f78d9759000+29000] > Oct 5 17:09:51 localhost kernel: postscreen[1310]: segfault at 0 ip > 7f372355dcea sp 7fff7569b520 error 4 in > libpostfix-util.so[7f3723543000+29000] > Oct 5 17:18:20 localhost kernel: postscreen[11822]: segfault at 0 ip > 7f4a3e9bfcea sp 7ffea70b09c0 error 4 in > libpostfix-util.so[7f4a3e9a5000+29000] > Oct 5 17:19:57 localhost kernel: postscreen[20595]: segfault at 0 ip > 7fe15ba10cea sp 7ffc68250090 error 4 in > libpostfix-util.so[7fe15b9f6000+29000] > Oct 5 17:21:38 localhost kernel: postscreen[11930]: segfault at 0 ip > 7fdf1de1fcea sp 7dfc02c0 error 4 in > libpostfix-util.so[7fdf1de05000+29000] > Oct 5 17:22:14 localhost kernel: postscreen[16126]: segfault at 0 ip > 7f69bc4ddcea sp 7ffeab170220 error 4 in > libpostfix-util.so[7f69bc4c3000+29000] > Oct 5 17:22:20 localhost kernel: postscreen[16138]: segfault at 0 ip > 7f7c9db76cea sp 7ffc3e818b70 error 4 in > libpostfix-util.so[7f7c9db5c000+29000] > Oct 5 17:27:18 localhost kernel: postscreen[22685]: segfault at 0 ip > 7f027d5a8cea sp 7ffc70a1b5f0 error 4 in > libpostfix-util.so[7f027d58e000+29000] > Oct 5 17:28:36 localhost kernel: postscreen[22746]: segfault at 0 ip > 7fd00d9f2cea sp 7fffb5133e70 error 4 in > libpostfix-util.so[7fd00d9d8000+29000] > Oct 5 17:28:36 localhost kernel: postscreen[22752]: segfault at 0 ip > 7f15ed50ecea sp 7fff054e0ea0 error 4 in > libpostfix-util.so[7f15ed4f4000+29000] > Oct 5 17:29:10 localhost kernel: postscreen[22764]: segfault at 0 ip > 7fbcf74becea sp 7ffc1c2a6840 error 4 in > libpostfix-util.so[7fbcf74a4000+29000] > Oct 5 17:29:16 localhost kernel: postscreen[22767]: segfault at 0 ip > 7f2c802b1cea sp 7ffd9c3d28f0 error 4 in > libpostfix-util.so[7f2c80297000+29000] > Oct 5 17:30:02 localhost kernel: postscreen[22771]: segfault at 0 ip > 7f388bc98cea sp 7ffc372ca850 error 4 in > libpostfix-util.so[7f388bc7e000+29000] > > both with postfix 3.5.6 and 3.5.7 on gentoo > > removed: > > postscreen_dnsbl_reply_map = > texthash:/etc/postfix/postscreen_dnsbl_reply_map > postscreen_dnsbl_sites = APIKEY.combined.mail.abusix.zone > > that removed the seqfaults > > kernel is 5.4.66, dont know if thats related to my problem, is other > seen that problem ? Support for postscreen_dnsbl_* not changed in years. You can try to attack a debugger as in http://www.postfix.org/DEBUG_README.html, to find out what function(s) are active at the time. Wietse
Re: Redirection using a 1:1 & domain wildcard alias
Dnia 5.10.2020 o godz. 17:28:04 Antonio Leding pisze: > * When both a 1:1 alias & a user are configured for a given email > address, why are emails sent to the alias\user only delivered to the > alias target? Because that's exactly what aliases are meant for - to deliver mail to the alias target *instead* of the original address. If you want the mail to be delivered *both* to alias target and to the original address, you must alias the original address to a *list* of both these addresses (I don't know if it works for virtual_alias_maps, it certainly works for aliases defined in /etc/aliases) > * When a domain wildcard alias & a user are configured, why are > emails sent to the user only delivered to the user and no copy to > the alias target? Because domain wildcard alias applies *by definition* for any address in the domain that *does not have* it's own alias defined. Once an address has it's own alias defined, wildcard alias is ignored. -- 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."
postscreen seqfaults with abusix rbl
Oct 5 17:01:09 localhost kernel: postscreen[387]: segfault at 0 ip 7f78d9773cea sp 7ffeb1cb0960 error 4 in libpostfix-util.so[7f78d9759000+29000] Oct 5 17:09:51 localhost kernel: postscreen[1310]: segfault at 0 ip 7f372355dcea sp 7fff7569b520 error 4 in libpostfix-util.so[7f3723543000+29000] Oct 5 17:18:20 localhost kernel: postscreen[11822]: segfault at 0 ip 7f4a3e9bfcea sp 7ffea70b09c0 error 4 in libpostfix-util.so[7f4a3e9a5000+29000] Oct 5 17:19:57 localhost kernel: postscreen[20595]: segfault at 0 ip 7fe15ba10cea sp 7ffc68250090 error 4 in libpostfix-util.so[7fe15b9f6000+29000] Oct 5 17:21:38 localhost kernel: postscreen[11930]: segfault at 0 ip 7fdf1de1fcea sp 7dfc02c0 error 4 in libpostfix-util.so[7fdf1de05000+29000] Oct 5 17:22:14 localhost kernel: postscreen[16126]: segfault at 0 ip 7f69bc4ddcea sp 7ffeab170220 error 4 in libpostfix-util.so[7f69bc4c3000+29000] Oct 5 17:22:20 localhost kernel: postscreen[16138]: segfault at 0 ip 7f7c9db76cea sp 7ffc3e818b70 error 4 in libpostfix-util.so[7f7c9db5c000+29000] Oct 5 17:27:18 localhost kernel: postscreen[22685]: segfault at 0 ip 7f027d5a8cea sp 7ffc70a1b5f0 error 4 in libpostfix-util.so[7f027d58e000+29000] Oct 5 17:28:36 localhost kernel: postscreen[22746]: segfault at 0 ip 7fd00d9f2cea sp 7fffb5133e70 error 4 in libpostfix-util.so[7fd00d9d8000+29000] Oct 5 17:28:36 localhost kernel: postscreen[22752]: segfault at 0 ip 7f15ed50ecea sp 7fff054e0ea0 error 4 in libpostfix-util.so[7f15ed4f4000+29000] Oct 5 17:29:10 localhost kernel: postscreen[22764]: segfault at 0 ip 7fbcf74becea sp 7ffc1c2a6840 error 4 in libpostfix-util.so[7fbcf74a4000+29000] Oct 5 17:29:16 localhost kernel: postscreen[22767]: segfault at 0 ip 7f2c802b1cea sp 7ffd9c3d28f0 error 4 in libpostfix-util.so[7f2c80297000+29000] Oct 5 17:30:02 localhost kernel: postscreen[22771]: segfault at 0 ip 7f388bc98cea sp 7ffc372ca850 error 4 in libpostfix-util.so[7f388bc7e000+29000] both with postfix 3.5.6 and 3.5.7 on gentoo removed: postscreen_dnsbl_reply_map = texthash:/etc/postfix/postscreen_dnsbl_reply_map postscreen_dnsbl_sites = APIKEY.combined.mail.abusix.zone that removed the seqfaults kernel is 5.4.66, dont know if thats related to my problem, is other seen that problem ?
Re: strange issue with postfix
Erik Thuning wrote: > Ranjan Maitra wrote: > > Thanks, I am not very knowledgeable with regard to postfix being a > > simple user, so do you mind letting me/us know what you had to fix? It > > is kind of forbidding to me. > > > > > Thank you! I had this exact issue and just couldn't wrap my head around > > > what was wrong, this solved things quite nicely. > > If you have different needs you should look into the links sent by Bob > earlier in this thread, there's quite a number of possible policies > available. Here is an old resource but one that I think is still very good is "Jim Seymour's suggestions/examples for Postfix anti-UCE configuration." http://jimsun.linxnet.com/misc/postfix-anti-UCE.txt That posting is filled with very useful, real world, down and dirty, practical information about Postfix configuration in the face of hostile spammers, backscatter, and other abuse. If you have trouble getting started on how things work together then I think that is a good guide to read through carefully. A few times! :-) Bob
Forward email based on Regexps
Hello;
I'm pretty new to postfix but I'm really glad that I finally made the
switch from sendmail. Postfix is just so much easier to use. This is my
scenario. I need to route emails based on regexps and I know how to write
them but I'm not exactly sure where in the configs to put them. For example,
I want to do this
/^To: [0-9]{10,11}@faxserver.acmewidgets.net/ faxadmin# The user
part is a fax number
/^To: [0-9]{10,11}@acmewidgets.net/ faxadmin#
The user part is a fax number
/^To: .*@acmewidgets.net/ admin
# Catch-all for the domain acmewidgets.com
/^To: .*@foo.com/
fooadmin # Catch-all for the domain foo.com
But I'm not sure these belong. Any insight at all would be greatly
appreciated.
Thanks;
Frank
Fwd: Redirection using a 1:1 & domain wildcard alias
I made an error in my statements below under **Observed behavior** - the last bullet point should read: * Last, to verify that the domain wildcard alias works, emails sent to [ ANY_USER_OR_ALIAS_NOT_CFG’D ]_at_example.com are delivered to user1_at_exmaple.com just as I expected (W00T!!!). :=) - - - Forwarded message: From: Antonio Leding To: Postfix users Subject: Redirection using a 1:1 & domain wildcard alias Date: Mon, 5 Oct 2020 17:28:04 + Hello Postfix Community, First off, I apologize if answers to my questions are well-known but before posting, I did spend a fair amount of time researching all of the Postfix READMEs, HOWTOs, etc. to try and understand this but apparently I am not finding the right information. Thanks in advance for your insights… - - - The scenario: * All domains, users, aliases, etc. are contained in SQL tables and defined in the main.cf as ‘virtual_mailbox_domains’, ‘virtual_mailbox_maps’, etc. * Two users are defined in the ‘virtual_mailbox_maps’ table. * user1_at_example.com * user2_at_example.com * There are two aliases defined in the ‘virtual_alias_maps’ table: * user2_at_example.com —> user1_at_example.com * @example.com —> user1_at_example.com Observed behavior: * If I send an email to user1_at_example.com, it is delivered as expected to the user1 mailbox. * If I send an email to user2_at_example.com, because of the alias, it is also delivered to the user1 mailbox but not to the user2 mailbox. * I expected a copy of the email to also be delivered to the user2 mailbox but it appears the alias prevents this and I’m not sure not sure why. * However, if I remove the alias for user2, then emails sent to user2 are delivered to the user2 mailbox (which makes sense) but nothing gets delivered to user1. * I expected the wildcard alias (@example.com) to cause a copy of the email to also be delivered to the user1 mailbox. * Last, to verify that the domain wildcard alias works, emails sent to [ ANYTHING ]_at_example.com are delivered to user1_at_exmaple.com just as I expected (W00T!!!). :=) Recap: * When both a 1:1 alias & a user are configured for a given email address, why are emails sent to the alias\user only delivered to the alias target? * When a domain wildcard alias & a user are configured, why are emails sent to the user only delivered to the user and no copy to the alias target?
Redirection using a 1:1 & domain wildcard alias
Hello Postfix Community, First off, I apologize if answers to my questions are well-known but before posting, I did spend a fair amount of time researching all of the Postfix READMEs, HOWTOs, etc. to try and understand this but apparently I am not finding the right information. Thanks in advance for your insights… - - - The scenario: * All domains, users, aliases, etc. are contained in SQL tables and defined in the main.cf as ‘virtual_mailbox_domains’, ‘virtual_mailbox_maps’, etc. * Two users are defined in the ‘virtual_mailbox_maps’ table. * user1_at_example.com * user2_at_example.com * There are two aliases defined in the ‘virtual_alias_maps’ table: * user2_at_example.com —> user1_at_example.com * @example.com —> user1_at_example.com Observed behavior: * If I send an email to user1_at_example.com, it is delivered as expected to the user1 mailbox. * If I send an email to user2_at_example.com, because of the alias, it is also delivered to the user1 mailbox but not to the user2 mailbox. * I expected a copy of the email to also be delivered to the user2 mailbox but it appears the alias prevents this and I’m not sure not sure why. * However, if I remove the alias for user2, then emails sent to user2 are delivered to the user2 mailbox (which makes sense) but nothing gets delivered to user1. * I expected the wildcard alias (@example.com) to cause a copy of the email to also be delivered to the user1 mailbox. * Last, to verify that the domain wildcard alias works, emails sent to [ ANYTHING ]_at_example.com are delivered to user1_at_exmaple.com just as I expected (W00T!!!). :=) Recap: * When both a 1:1 alias & a user are configured for a given email address, why are emails sent to the alias\user only delivered to the alias target? * When a domain wildcard alias & a user are configured, why are emails sent to the user only delivered to the user and no copy to the alias target?
Re: Accessing the sending user from a canonical(5) table
Demi M. Obenour: > On 2020-10-04 19:55, Wietse Venema wrote: > > Demi M. Obenour: > > > > Checking application/pgp-signature: FAILURE > > -- Start of PGP signed section. > >> On 2020-09-30 16:35, Wietse Venema wrote: > >>> Demi M. Obenour: > - If a message arrives via the SMTPS or submission ports, I > want to replace the address part of the user-supplied From: > header with the envelope From: header. This allows me to use > reject-sender-login-mismatch to prevent users from sending messages > with forged From: addresses. > >>> > >>> There are two parts to this: > >>> > >>> 1) Locking down the envelope.from. > >>> > >>>With authenticated smtp submission, the envelope.from can be > >>>constrained by smtpd_sender_login_maps. > >>> > >>>With sendmail/postdrop submission the UNIX login name can be > >>>overidden with "sendmail -f". There is no code in Postfix to > >>>lock down "sendmail -f", and there is no 'plugin' interface that > >>>could do this, either. I don't like the idea of adding complex > >>>logic to the set-gid postdrop command to lock down "sendmail > >>>-f". Doing the lockdown in the pickup daemon would be more > >>>secure but has the problem that the 'reject' happens too late. > >> > >> I looked at the postdrop source code to see what locking down "sendmail > >> -f" would entail. Checking that the current user can use `-f` seems > >> to be just looking up the current username in an ACL, which postdrop > >> already does for authorized_submit_users. Checking that -f was not > >> passed looks to just be a string equality check, unless I am missing > >> something. Of course, converting the same UID to a username three > >> times is not a good idea performance-wise, but that can be fixed with > >> some minor refactoring. > >> > >> Another option is to emit a good error message from sendmail, and then > >> do the security check in pickup. If a user calls postdrop directly, > >> the reject will happen late, but my understanding is that this isn't > >> supported. > >> > >> Would you be interested in a patch that implemented either of these > >> options? > > > > I think that the envelope.from lockdown should be enforced in pickup > > or before pickup but not both. If it is both then the code in the > > pickup daemon will be a NOOP. WHen code is usually a NOOP no-one will > > notice when they break it. > > > > If a sender_login_maps feature can be implemented in postdrop > > without giving an untrusted user control over the programn, then > > let's try that. > > I would be willing to try, but I suggest we only support ?simple? > maps here. Postfix supports a wide variety of map types, and I would > rather not expose that much attack surface in postdrop. Furthermore, > in all of the use cases I can think of, a simple policy is fine. I have no idea what that means. Postfix has a separation between lookup mechanisms (hash, pcre) and table-driven mechanisms (access maps, smtp_sender_login_maps). If you are thinking of skipping the Postfix dictionary API and crafting your own table lookups, then that is definiitely not going to happen. > What about allowing everyone to send mail as themselves, and having > a list of users who can send mail as anyone? That is what Sendmail > provides. If a delimiter is specified in the configuration, it would > be honored. By default, a user can send mail as everyone, and that default behavior cannot be changed. So the question becomes: what is the behavior? I think it should behave like smtp_sender_login_maps, because there is no reason to invent new behavior. This means the search string is the UNIX username, and the lookup result is a comma-separated list of things (usernames and/or email addresses) that they may specify as the envelope sender address. Your 'identity' mapping then looks like this: /etc/postfix/main.cf: local_sender_login_maps = pcre:/etc/postfix/local_sender_logins /etc/postfix/local_sender_logins /(.+)/ $1, $1...@example.com I.e. a user can send mail only if the envelope sender equals their login name, or usern...@example.com. There will need to be a wildcard pattern that allows all, as would be needed by a content filter that re-injects mail using the Postfix sendmail command. We just need to make sure that maps are opened after postdrop has stripped the environment, set up signal handlers, and done other steps against misuse. In that light, I'll move the existing check_user_acl_byuid() call down, after the comment that says 'End of initializations". A note about etiquette: my posts clearly say "Reply-To: postfix-users@postfix.org". Please fix your MUA and stop sending your response to my personal email address. Wietse
Alter virtual domains MySQL table to insert relay host for some domains
Hi all, I'm running a personal Postfix mail server together with Courier for a virtual domain setup. By now I have a domains table with a single transport field which is used by transport_maps directive in order to know if incoming emails must be delivered locally or need to be sent to the next hop. The thing is I would like to be able to receive email for domain example.com, as i've been doing so far, but I also would like to be able to relay the outgoing emails for example.com to another domain like smtp-relay.gmail.com. So, after reading the transport [1] documentation I'm a bit confused. As I understand I would need to create a new field in the domains table called relay_transport and edit the $transport_maps MySQL query. If I understand it correctly, $transport_maps query's result should be the same as now but for those domains using an external relay the result should be something like virtual:smtp-relay.gmail.com, is it right? Also, I just wanted to ask: 1. Is there any misunderstanding in the previous logic? 2. Is $transport_maps MySQL query used in other postfix workflow that I may missed? I do not want to make changes before understanding their impact. 3. If I would have to add a user and a password for authenticating to the relay, which settings should I take into account? Thanks for your help, [1] http://www.postfix.org/transport.5.html -- 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: Backwards-compatibility setting
Erik Thuning: > Hi! > > I noticed my site is running compatibility_level=0, which I want to > change. From what I can gather at > http://www.postfix.org/COMPATIBILITY_README.html, it seems that the > compatibility messages largely get triggered when postfix comes across a > message where they are relevant, not on service startup etc. > > So, I ran a quick check through all my servers' mail logs (4 weeks back) > looking for these messages, and nothing showed up. Given that these logs > actually reflect typical usage, it seems like I'm in the clear. > > Is there anything else I can do to verify that none of my setings will > get changed in a surprising manner when switching compatibility levels? You are doing the right thing. If no warnings trigger, then the compatibility_level should be safe to change without visible effects. Wietse
Re: Documentation Correction
Peter: > I just noticed this in SASL_README > (http://www.postfix.org/SASL_README.html#client_sasl_enable): > >* The Postfix SMTP client does not support the obsolete "wrappermode" > protocol, which uses TCP port 465 on the SMTP server. See > TLS_README for a > solution that uses the stunnel command. > > I believe this is out of date as wrappermode has been available for smtp > for some time now and submissions is a thing now so the protocol is no > longer obsolete either. I have updated some text in SASL_README and TLS_README. Wietse
Backwards-compatibility setting
Hi! I noticed my site is running compatibility_level=0, which I want to change. From what I can gather at http://www.postfix.org/COMPATIBILITY_README.html, it seems that the compatibility messages largely get triggered when postfix comes across a message where they are relevant, not on service startup etc. So, I ran a quick check through all my servers' mail logs (4 weeks back) looking for these messages, and nothing showed up. Given that these logs actually reflect typical usage, it seems like I'm in the clear. Is there anything else I can do to verify that none of my setings will get changed in a surprising manner when switching compatibility levels? Thanks, Erik
Re: strange issue with postfix
I set the following in main.cf: smtpd_relay_restrictions = permit_mynetworks, reject Which, if I understand correctly, should mean that any email coming from addresses specified in mynetworks will be accepted, while all others get rejected. Mynetworks in my case only specifies loopback addresses, so my SMTP server will accept email from localhost and reject all others. If you have different needs you should look into the links sent by Bob earlier in this thread, there's quite a number of possible policies available. /T On 2020-10-02 19:55, Ranjan Maitra wrote: Hi, Thanks, I am not very knowledgeable with regard to postfix being a simple user, so do you mind letting me/us know what you had to fix? It is kind of forbidding to me. Thanks again and best wishes, Ranjan On Fri, 2 Oct 2020 15:52:34 +0200 Erik Thuning wrote: > Thank you! I had this exact issue and just couldn't wrap my head around > what was wrong, this solved things quite nicely. > > /T > > On 2020-10-02 00:00, Bob Proulx wrote: > > Ranjan Maitra wrote: > > > > > Oct 1 14:08:00 localhost postfix/smtpd[4142479]: fatal: in > > parameter smtpd_relay_restrictions or smtpd_recipient_restrictions, > > specify at least one working instance of: reject_unauth_destination, > > defer_unauth_destination, reject, defer, defer_if_permit or > > check_relay_domains > > > > > > My apologies: how do I do this/what should I do here? > > > > Since you haven't shared your postfix configuration but just parts of > > it in the master.cf then we can only point to the documentation. > > > > Start here and read these: > > > > http://www.postfix.org/postconf.5.html#smtpd_relay_restrictions > > > > http://www.postfix.org/postconf.5.html#smtpd_recipient_restrictions > > > > What is the value of these for you? This will produce some output > > which shows the current configuration. > > > > postconf smtpd_recipient_restrictions smtpd_relay_restrictions > > > > For my use I leave smtpd_relay_restrictions set to the default value > > and then set smtpd_recipient_restrictions. That's one valid > > combination. But there are others. > > > > At the least I would think something like this: > > > > smtpd_recipient_restrictions = > > permit_mynetworks, > > reject_unauth_destination, > > reject_invalid_hostname, > > reject_non_fqdn_hostname, > > reject_non_fqdn_sender, > > reject_non_fqdn_recipient, > > reject_unknown_sender_domain, > > reject_unknown_recipient_domain > > > > But in real use I have a much longer list with a lot more there for > > blocking spam and other things. You should understand it before using > > it and adjust it as needed for your environment. > > > > Bob > -- Important Notice: This mailbox is ignored: e-mails are set to be deleted on receipt. Please respond to the mailing list if appropriate. For those needing to send personal or professional e-mail, please use appropriate addresses.
