Re: BBC mapping
@lbutlr:
> if !/backup.*@/
> /^([^+_]*).*@(.*)/ backup+${1}.${2}@domain.tld
> endif
>
> I currently have the above in recipient_bbc
>
> /etc/postfix/main.cf:
>
> recipient_bcc_maps =3D pcre:$config_directory/recipient_bcc.pcre
>
> And this works perfectly and stores a copy of all email (sent and =
> received) in a backup account that is set to delete messages after 7 =
> days. This allows me to recover messages which people have deleted or =
> accidentally marked as spam.
>
> However, I would like to exclude a specific domain from this backup =
> including all mail TO and FROM the domain.
if !/backup.*@/
if !/@example\.com$/
/^([^+_]*).*@(.*)/ backup+${1}.${2}@domain.tld
endif
endif
However the first pattern doesn't seem robust to me. It excludes
something that has 'backup' in the middle of the localpart.
Wietse
BBC mapping
if !/backup.*@/
/^([^+_]*).*@(.*)/ backup+${1}.${2}@domain.tld
endif
I currently have the above in recipient_bbc
/etc/postfix/main.cf:
recipient_bcc_maps = pcre:$config_directory/recipient_bcc.pcre
And this works perfectly and stores a copy of all email (sent and received) in
a backup account that is set to delete messages after 7 days. This allows me to
recover messages which people have deleted or accidentally marked as spam.
However, I would like to exclude a specific domain from this backup including
all mail TO and FROM the domain.
--
Apple broke AppleScripting signatures in Mail.app, so no random signatures.
Re: “From:” address is ignored despite sender_login_maps
Stephan: > Hi list, > > I am having a bad time setting up a postifx configuration that allows > sending mails only when the sender actually "owns" the "From:"-address. There is no such feature in Postfix. Postfix can control the MAIL FROM address in SMTP commands, not the From header. Wietse
“From:” address is ignored despite sender_login_maps
Hi list,
I am having a bad time setting up a postifx configuration that allows
sending mails only when the sender actually "owns" the "From:"-address.
I manage multiple domains the the login names are full qualified email
addresses as well. My "alias" table looks like this (goto is the login name)
+---+--+++
| address | goto | domain | active |
+---+--+++
| ali...@domain.tld | us...@domain.tld | domain.tld | 1 |
| ali...@domain.tld | us...@domain.tld | domain.tld | 1 |
+---+--+++
and I want user1 to be able to send with "From: alias1@..." but not with
"From: alias2@...".
The corresponding query in sender_login_maps.cf reads "SELECT goto FROM
alias WHERE address='%s' AND active = 1".
So I put 'reject_authenticated_sender_login_mismatch' in
'smtpd_sender_restrictions' (see below for config files) but I still can
send with any "From:"-address I want, e.g. madeup@not_my_domain.com. Now
comes the strange part:
The query itself works fine, because when I change it to "SELECT goto
FROM alias WHERE address='not_in_database_for_sure' AND active = 1", I
can't send any mails at all, as the address is not found.
But when I try to send an email with "From: madeup@not_my_domain.com"
the mysql server logs the following:
"postfix/smtps/smtpd[11683]: NOQUEUE: reject: RCPT from...: 553 5.7.1
:
Sender address rejected: not owned by user us...@domain.tld;
from= to= proto=ESMTP
helo=<[192.168.2.103]>"
while I would have expected
"postfix/smtps/smtpd[11683]: NOQUEUE: reject: RCPT from...: 553 5.7.1
:
Sender address rejected: not owned by user us...@domain.tld;
from= to= proto=ESMTP
helo=<[192.168.2.103]>"
So it looks like the mysql-server never actually sees
"madeup@not_my_domain.com" but only "us...@domain.tld", which is valid.
There is no address rewriting though, because the delivered mails are
always send "From: ".
I had asked this question already here
(https://unix.stackexchange.com/questions/330017/postfix-does-not-check-from-address-with-sender-login-maps),
so feel free to answer there as well.
Here are 'postconf -nf' and 'postconf -Mf':
--
alias_maps = hash:/etc/aliases
append_dot_mydomain = no
biff = no
bounce_queue_lifetime = 1h
config_directory = /etc/postfix
inet_interfaces = all
lmtp_tls_mandatory_protocols = !SSLv2, !SSLv3
lmtp_tls_protocols = !SSLv2, !SSLv3
mailbox_size_limit = 0
maximal_backoff_time = 15m
maximal_queue_lifetime = 1h
message_size_limit = 52428800
minimal_backoff_time = 5m
mydestination =
mydomain = domain.tld
myhostname = mail.domain.tld
mynetworks = 127.0.0.0/8
myorigin = $mydomain
postscreen_access_list = permit_mynetworks
cidr:/etc/postfix/postscreen_access
postscreen_blacklist_action = drop
postscreen_dnsbl_action = drop
postscreen_dnsbl_sites = dnsbl.sorbs.net*1, bl.spamcop.net*1,
ix.dnsbl.manitu.net*2, zen.spamhaus.org*2
postscreen_dnsbl_threshold = 2
postscreen_greet_action = drop
queue_run_delay = 5m
recipient_delimiter = +
relay_domains = mysql:/etc/postfix/sql/relay_domains.cf
relayhost =
smtp_dns_support_level = dnssec
smtp_tls_CAfile = /etc/ssl/certs/ca-certificates.crt
smtp_tls_ciphers = high
smtp_tls_mandatory_protocols = !SSLv2, !SSLv3
smtp_tls_protocols = !SSLv2, !SSLv3
smtp_tls_security_level = dane
smtp_tls_session_cache_database = btree:${data_directory}/smtp_scache
smtpd_data_restrictions = reject_unauth_pipelining
smtpd_helo_required = yes
smtpd_helo_restrictions = permit_mynetworks reject_invalid_helo_hostname
reject_non_fqdn_helo_hostname reject_unknown_helo_hostname
smtpd_recipient_restrictions = reject_sender_login_mismatch,
permit_mynetworks,
permit_sasl_authenticated, reject_non_fqdn_hostname,
reject_non_fqdn_recipient, reject_unauth_destination,
reject_unauth_pipelining, reject_invalid_hostname
smtpd_relay_restrictions = permit_mynetworks, permit_sasl_authenticated,
reject_unauth_destination, reject_non_fqdn_recipient
smtpd_sasl_auth_enable = yes
smtpd_sasl_path = private/auth
smtpd_sasl_security_options = noanonymous, noplaintext
smtpd_sasl_type = dovecot
smtpd_sender_login_maps = mysql:/etc/postfix/sql/sender_login_maps.cf
smtpd_sender_restrictions = reject_non_fqdn_sender,
reject_unknown_sender_domain, reject_unauth_pipelining,
reject_authenticated_sender_login_mismatch, permit_sasl_authenticated
smtpd_tls_auth_only = yes
smtpd_tls_cert_file = /home/letsencrypt/certificate/chained.pem
smtpd_tls_ciphers = high
smtpd_tls_dh1024_param_file = /etc/ssl/dhparams8192.pem
smtpd_tls_key_file = /home/letsencrypt/keys/domain.key
smtpd_tls_mandatory_protocols = !SSLv2, !SSLv3
smtpd_tls_protocols = !SSLv2, !SSLv3
smtpd_tls_security_level = may
smtpd_tls_session_cache_database = btree:${data_directory}/smtpd_scache
tls_high_cipherlist
Re: Postfix redirects emails to postmaster for non-existent users
Thank you very much, sir. Much appreciated. Süleyman Düzdaban Ankara Üniversitesi Bilgi İşlem Daire Başkanlığı - Sistem Grubu 0312 215 90 01 (Dahili: 3033) On 02/07/2017 05:03 PM, Viktor Dukhovni wrote: >> On Feb 7, 2017, at 7:59 AM, Süleyman Düzdaban >> wrote: >> >> When I remove the record (For example, @ankara.edu.tr) from "alias" >> table then I can get "Recipient address rejected: User unknown in >> virtual mailbox table" message and that's what I want. >> So I can remove all of that records from database, right? > Removing these will lead to better handling of non-existent > recipients, what I can't say is whether this may adversely > affect delivery of some "existent" or otherwise wanted email. > > You need to determine what these wildcard mappings are for. >
Re: Postfix redirects emails to postmaster for non-existent users
> On Feb 7, 2017, at 7:59 AM, Süleyman Düzdaban > wrote: > > When I remove the record (For example, @ankara.edu.tr) from "alias" > table then I can get "Recipient address rejected: User unknown in > virtual mailbox table" message and that's what I want. > So I can remove all of that records from database, right? Removing these will lead to better handling of non-existent recipients, what I can't say is whether this may adversely affect delivery of some "existent" or otherwise wanted email. You need to determine what these wildcard mappings are for. -- Viktor.
Re: Postfix redirects emails to postmaster for non-existent users
Yes, you're right sir, we have for all of our domains ("postmap -q
@ankara.edu.tr(or other subdomains)
mysql:$config_directory/maps/sql-valiases.cf" yields some return value).
When I remove the record (For example, @ankara.edu.tr) from "alias"
table then I can get "Recipient address rejected: User unknown in
virtual mailbox table" message and that's what I want.
So I can remove all of that records from database, right?
Süleyman Düzdaban
Ankara Üniversitesi
Bilgi İşlem Daire Başkanlığı - Sistem Grubu
0312 215 90 01 (Dahili: 3033)
On 02/06/2017 07:03 PM, Viktor Dukhovni wrote:
> On Mon, Feb 06, 2017 at 05:37:27PM +0300, Süleyman Düzdaban wrote:
>
>>> Be specific, what type of domain is "mydomain":
>>>
>>> Please be very clear whether you're trying to reject mail *to*
>>> non-existent recipients, or *from* non-existent senders. I am
>>> assuming "recipients" for now based on the above.
>> I mean virtual mailbox domain listed in $virtual_mailbox_domains.
>>
virtual_mailbox_domains =
proxy:mysql:$config_directory/maps/sql-vdomains.cf
>>> Any domains listed there?
>> Yes. All of our domains (ankara.edu.tr,
>> agri.ankara.edu.tr,politics.ankara.edu.tr etc.) and "postmap -q
>> existent-domain proxy:mysql:$config_directory/maps/sql-vdomains.cf"
>> yields return value "virtual:" for the existent-domains and nothing for
>> the non-existent-domains.
> For domains listed in virtual_mailbox_domains the Postfix smtpd(8)
> server rejects mail to addresses that are not listed in any of:
>
> recipient_canonical_maps
> canonical_maps
> virtual_alias_maps
> virtual_mailbox_maps
>
> Perhaps you have wildcard mappings in one of these. Based on your
> reported configuration, that would be virtual_alias_maps or
> virtual_mailbox_maps. Any output from:
>
> $ config_directory=$(postconf -hx config_directory)
> $ postmap -q @ankara.edu.tr mysql:$config_directory/maps/sql-valiases.cf
> $ postmap -q @ankara.edu.tr mysql:$config_directory/maps/sql-vmailboxes.cf
>
Re: Antispamming with header checks and regexp
Hi Istvan,
> Noel Jones wrote:
> > Remember that header_checks won't match encoded subjects
We need to see the raw Subject header from the email that failed to
match. It was probably encoded.
$ scan -forma '%{subject}' .
=?UTF-8?B?VGhpcyBpcyBzcGFtLgo=?=
$ scan -forma '%(decode{subject})' .
This is spam.
$ grep -i '^subject:' `mhpath .`
Subject: =?UTF-8?B?VGhpcyBpcyBzcGFtLgo=?=
$
It's to allow non-ASCII characters in the some of the headers, e.g.
Subject.
--
Cheers, Ralph.
https://plus.google.com/+RalphCorderoy
Re: Antispamming with header checks and regexp
On 2017-02-06 23:19, Noel Jones wrote: On 2/6/2017 3:23 PM, Istvan Prosinger wrote: Hi All, and Happy New Year with a little delay :) Comming to spam, header checks are one tool that I use frequently to prevent it. So, amongst all, I have this: if !/^Subject: (.*)[Aa]liexpress/ /^Subject:(.*)% [Oo][Ff][Ff]/ REJECT Go away spammer endif And this worked fine until _today_, when I got one email (and it wasn't from Ali) that had a subject: You’re In Luck | Up to 70% Off As for the regexp, I think this should definitely be a hit, but it got thru. First I thought that something bugged because of the | sign, but no. I've sent several tests from an external account and it's geting thru. I need a 4-eye method - what the heck am I missing here? Best, Istvan Oy, what an awkwardly awkward redundant expression that is up there above. Postfix regular expressions are case-insensitive by default, so the [Aa] nonsense is unnecessary. Encapsulating the wildcards with () This doesn't matter at all. That said, your expression probably mostly works. Ha! That helped a lot. I aleady know that it "mostly works", it just doesn't work in this case. I do respect your work on this list, bit you have completely missed my point. I'm trying to understand what happend, not looking for a "better suggestion". Remember that header_checks won't match encoded subjects, and only one action is allowed per header, so if this header hits any prior rules (such as a WARN, INFO, DUNNO) then it won't be rejected. It didn't hit anything else prior to this rule.
Re: Antispamming with header checks and regexp
On 2017-02-06 22:56, Dominic Raferd wrote: On 6 February 2017 at 21:23, Istvan Prosinger wrote: Hi All, and Happy New Year with a little delay :) Comming to spam, header checks are one tool that I use frequently to prevent it. So, amongst all, I have this: if !/^Subject: (.*)[Aa]liexpress/ /^Subject:(.*)% [Oo][Ff][Ff]/ REJECT Go away spammer endif And this worked fine until _today_, when I got one email (and it wasn't from Ali) that had a subject: You’re In Luck | Up to 70% Off As for the regexp, I think this should definitely be a hit, but it got thru. First I thought that something bugged because of the | sign, but no. I've sent several tests from an external account and it's geting thru. I need a 4-eye method - what the heck am I missing here? Try removing the round brackets... Why?
