On 1 Nov 2016, at 1:46, @lbutlr wrote:
On Oct 31, 2016, at 8:49 PM, Bill Cole
<postfixlists-070...@billmail.scconsult.com> wrote:
On 31 Oct 2016, at 22:04, @lbutlr wrote:
On 31 Oct 2016, at 17:08, wilfried.es...@essignetz.de wrote:
Am 31.10.2016 um 23:51 schrieb @lbutlr:
...
No loglines of the denied mail?
Sure. Ut gives the same error as in the DND email.
Oct 31 09:34:19 mail postfix/smtpd[35893]: 3t6z1R27xYzKXmh:
client=localhost[127.0.0.1]
Oct 31 09:34:19 mail postfix/smtpd[35893]: 3t6z1R27xYzKXmh: permit:
DATA from localhost[127.0.0.1]: action=permit for Data command=DATA
; from=<virusal...@covisp.net> to=<virusal...@covisp.net>
proto=ESMTP helo=<mail.covisp.net>
Oct 31 09:34:19 mail postfix/cleanup[35866]: 3t6z1R27xYzKXmh:
message-id=<valec8gtk8d...@mail.covisp.net>
Oct 31 09:34:19 mail postfix/qmgr[1309]: 3t6z1R27xYzKXmh:
from=<virusal...@covisp.net>, size=3114, nrcpt=1 (queue active)
Oct 31 09:34:19 mail postfix/local[35894]: 3t6z1R27xYzKXmh:
to=<virusal...@covisp.net>, relay=local, delay=0.13,
delays=0.08/0.03/0/0.02, dsn=5.1.1, status=bounced (unknown user:
"virusalert")
Oct 31 09:34:19 mail postfix/bounce[35895]: 3t6z1R27xYzKXmh: sender
non-delivery notification: 3t6z1R33w3zKYKC
If I manually send a mail to virusal...@covisp.net
What do you mean with "manually”?
Sent it myself from remote email (gmail or iCloud)
(What is the difference to the denied mail?)
virusalert is the email that amavis sends to, but it is postfix that
is rejecting it.
PLease, provide output of postconf -n and postconf -Mf.
OK, But I don’t think that is going to be helpful in this case.
the user is valid. The user maps properly via postmap -q, so there
is something else that is causing this.
There are no errors, panics, or fatal messages and the only warning
messages are rbl-related.
But I see 2 possible issues. The first almost certain:
mydestination = $myhostname, localhost.$mydomain, $mydomain,
localhost,
ns1.$mydomain, ns2.$mydomain, mail.$mydomain, www.$mydomain,
webmail.$mydomain
mydomain = covisp.net
[...]
virtual_alias_domains = kreme.com
virtual_alias_maps = hash:$config_directory/virtual
proxy:mysql:$config_directory/mysql_virtual_alias_maps.cf
So: on what basis would you expect virusal...@covisp.net to be
mapped as a virtual alias? You've told Postfix that covisp.net is a
local domain and that only kreme.com addresses should be mapped via
virtual aliases. I don't see how this can ever work…
And as Viktor has pointed out, I'm wrong here. Apparently
virtual_domains does not mean what I thought it did (gotta go re-read
docs...)
And yet it works in every case except amavisd sending the mail.
Of course: amavisd is passing mail directly to the post-amavisd (port
10025) instance of smtpd, which has "no_address_mappings" set. To expand
the virtual alias that cannot be set. The expansion is only done in the
pre-amavisd smtpd. See the FILTER_README and note that you are using
filter and post-filter port numbers one less than the "Advanced"
example: 10024 and 10025 instead of 10025 and 10026.
There are multiple conceptual ways to fix this, but I'm not sure which
would be easiest for you to actually do. Easiest: add
receive_override_options=no_address_mappings to the pre-filter smtpd,
and remove no_address_mappings from the post-filter
receive_override_options. That may have bad side-effects if you have
amavisd configured in a way that relies on virtual aliases already being
resolved.
I can sit at the command line of the mail server and send a mail to
the account and it is delivered.
Oct 31 23:38:11 mail postfix/smtp[87418]: 3t7Kl66CDqzKXmY:
to=<ad...@covisp.net>, orig_to=<virusal...@covisp.net>,
relay=127.0.0.1[127.0.0.1]:10024, delay=0.46, delays=0.02/0.02/0/0.41,
dsn=2.0.0, status=sent (250 2.0.0 from MTA(smtp:[127.0.0.1]:10025):
250 2.0.0 Ok: queued as 3t7Kl725lkzKXmh)
Oct 31 23:38:21 mail postfix/smtp[87418]: 3t7KlK0L21zKYP8:
to=<ad...@covisp.net>, orig_to=<virusalert>,
relay=127.0.0.1[127.0.0.1]:10024, delay=0.43, delays=0.01/0/0/0.42,
dsn=2.0.0, status=sent (250 2.0.0 from MTA(smtp:[127.0.0.1]:10025):
250 2.0.0 Ok: queued as 3t7KlK3C2vzKYPB)
So, local with domain, local without domain, and remote with domain
all get delivered but for some reason when amazes injects the email,
postfix decides the username is invalid.
Also, I bet you'd see what's happening more clearly with syslog_name
set in a '-o' line for this service:
OK, but I think amazes logs pretty well as amavisd.
I expect that is true, however this is smtpd, NOT amavisd. It's the
backend Postfix process that amavisd passes messages to. The amavisd
process is listening on 10024 according to your config. This is the
Postfix smtpd that listens on 10025, which has only amavisd as a client.
(Normally...)
Generally speaking, Postfix problem analysis (and auditing) is helped a
great deal by making sure that if you have multiple services using the
same executable (e.g. smtpd) then you have a unique syslog_name for each
one. Both this smtpd instance and the submission smtpd should get
syslog_name overrides so that you can tell which config is in effect for
the various log lines.
127.0.0.1:10025 inet n - n - - smtpd
-o content_filter=
-o local_recipient_maps=
-o relay_recipient_maps=
-o smtpd_restriction_classes=
-o smtpd_client_restrictions=
-o smtpd_helo_restrictions=
-o smtpd_sender_restrictions=
-o smtpd_recipient_restrictions=permit_mynetworks,reject
-o mynetworks=127.0.0.0/8
-o strict_rfc821_envelopes=yes
-o smtpd_error_sleep_time=0
-o smtpd_soft_error_limit=1001
-o smtpd_hard_error_limit=1000
-o
receive_override_options=no_header_body_checks,no_unknown_recipient_checks,no_address_mappings
I suspect no_address_mappings isn't appropriate here. It disables
virtual aliases, so you're doing that ahead of amavisd, which may be
OK but to quote postconf(5):
That is the amavis port, and it breaks without no_address_map
Please, humor me: set syslog_name and retest. Your posted tests make it
clear that SOME smtpd is passing a message to 'local' without expanding
the virtual alias. The ones that work show SOME smtpd passing a message
through amavisd (port 10024, which is responding with an assertion that
port 10025 accepted it) and expanding the virtual alias ahead of that.
Differentiate the different smtpd instances and your logs will reveal
what is happening more clearly.
