Log Messages

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
10 messages Options
Reply | Threaded
Open this post in threaded view
|

Log Messages

wa6vvv
I am running a mail server that has a few local recipients and a bunch of forwarded recipients for one domain.  All is working properly.  However, there are some log messages that I find confusing.  The server receives many messages delivery attempts where the user is not included in the virtual_alias_maps.  All but one of them receive log messages like

Recipient address rejected: unverified address

That makes sense.  However, one of them receives

Recipient address rejected: User unknown in virtual alias table

I don't see what is different for this particular user.  They all have the same domain which is the only one in virtual_alias_domains.  It appears that that message made it through the smtpd check as if the user was in the virtual_alias_maps.  That user id does not appear anywhere in the postfix configuration.  Am I interpreting these messages correctly?

One possible issue with this user was that that id was originally not in virtual_alias_maps and was added.  There were no such log messages before that.  They were listed in the unverified address listing.  After adding the user, there were no log messages and mail was delivered.  Later the address was removed from virtual_alias_maps and then the unknown messages started.  Postfix was re-started after that change was made (not a reload).

-- Doug

Reply | Threaded
Open this post in threaded view
|

Re: Log Messages

Wietse Venema
Doug Hardie:

> I am running a mail server that has a few local recipients and a bunch of forwarded recipients for one domain.  All is working properly.  However, there are some log messages that I find confusing.  The server receives many messages delivery attempts where the user is not included in the virtual_alias_maps.  All but one of them receive log messages like
>
> Recipient address rejected: unverified address
>
> That makes sense.  However, one of them receives
>
> Recipient address rejected: User unknown in virtual alias table
>
> I don't see what is different for this particular user.  They all
> have the same domain which is the only one in virtual_alias_domains.
> It appears that that message made it through the smtpd check as
> if the user was in the virtual_alias_maps.  That user id does not
> appear anywhere in the postfix configuration.  Am I interpreting
> these messages correctly?
>
> One possible issue with this user was that that id was originally
> not in virtual_alias_maps and was added.  There were no such log
> messages before that.  They were listed in the unverified address
> listing.  After adding the user, there were no log messages and
> mail was delivered.  Later the address was removed from
> virtual_alias_maps and then the unknown messages started.  Postfix
> was re-started after that change was made (not a reload).

Without actual configuration and actual (anonymized)
logs, it's anyone's guess what is/was happening.

        Wietse
Reply | Threaded
Open this post in threaded view
|

Re: Log Messages

/dev/rob0
In reply to this post by wa6vvv
On Wed, May 23, 2018 at 08:39:08AM -0700, Doug Hardie wrote:
> I am running a mail server that has a few local recipients and a
> bunch of forwarded recipients for one domain.  All is working
> properly.  However, there are some log messages that I find
> confusing.  The server receives many messages delivery attempts
> where the user is not included in the virtual_alias_maps.  All but
> one of them receive log messages like
>
> Recipient address rejected: unverified address

This was rejected by the reject_unverified_recipient smtpd
restriction, after an attempt to verify the address failed.

> That makes sense.  However, one of them receives
>
> Recipient address rejected: User unknown in virtual alias table

This was rejected by the reject_unauth_destination smtpd
restriction, probably in smtpd_relay_restrictions, and means that
the domain was found in virtual_alias_domains, but the address did
not resolve via v_a_maps to an address NOT in v_a_domains.

> I don't see what is different for this particular user.

Is it a "user" or just a non-existent address?  If the former, you
have a problem.  If the latter, it's fine.
--
  http://rob0.nodns4.us/
  Offlist GMX mail is seen only if "/dev/rob0" is in the Subject:
Reply | Threaded
Open this post in threaded view
|

Re: Log Messages

wa6vvv
> On 23 May 2018, at 09:24, /dev/rob0 <[hidden email]> wrote:
>
> On Wed, May 23, 2018 at 08:39:08AM -0700, Doug Hardie wrote:
>> I am running a mail server that has a few local recipients and a
>> bunch of forwarded recipients for one domain.  All is working
>> properly.  However, there are some log messages that I find
>> confusing.  The server receives many messages delivery attempts
>> where the user is not included in the virtual_alias_maps.  All but
>> one of them receive log messages like
>>
>> Recipient address rejected: unverified address
>
> This was rejected by the reject_unverified_recipient smtpd
> restriction, after an attempt to verify the address failed.
>
>> That makes sense.  However, one of them receives
>>
>> Recipient address rejected: User unknown in virtual alias table
>
> This was rejected by the reject_unauth_destination smtpd
> restriction, probably in smtpd_relay_restrictions, and means that
> the domain was found in virtual_alias_domains, but the address did
> not resolve via v_a_maps to an address NOT in v_a_domains.
>
>> I don't see what is different for this particular user.
>
> Is it a "user" or just a non-existent address?  If the former, you
> have a problem.  If the latter, it's fine.

It is a non-existent address and is fine.  It's just surprising that one of the non-existent addresses gets a different log message.  The only thing I can think of is that the originator has a non-printing character somewhere in the address.


Reply | Threaded
Open this post in threaded view
|

Re: Log Messages

Viktor Dukhovni


> On May 23, 2018, at 2:23 PM, Doug Hardie <[hidden email]> wrote:
>
> It is a non-existent address and is fine.  It's just surprising that one of the non-existent addresses gets a different log message.  The only thing I can think of is that the originator has a non-printing character somewhere in the address.

No, the reason is that the address existed in the past, and
so is cached as verified.  That cached value will expire at
some point, and then it will become unverified.  Not clear
why you use recipient verification...

--
        Viktor.

Reply | Threaded
Open this post in threaded view
|

Re: Log Messages

wa6vvv
> On 23 May 2018, at 11:43, Viktor Dukhovni <[hidden email]> wrote:
>
>
>
>> On May 23, 2018, at 2:23 PM, Doug Hardie <[hidden email]> wrote:
>>
>> It is a non-existent address and is fine.  It's just surprising that one of the non-existent addresses gets a different log message.  The only thing I can think of is that the originator has a non-printing character somewhere in the address.
>
> No, the reason is that the address existed in the past, and
> so is cached as verified.  That cached value will expire at
> some point, and then it will become unverified.  Not clear
> why you use recipient verification...


I would think that cache would be cleared with a restart.  Vmail_alias is dated 28 Apr.  That's almost 2 months ago.  Recipient verification seemed like a good idea from reading the documentation.  I take it from your comment that it duplicates one of the other checks?

incoming_smtpd_restrictions =
        check_policy_service inet:127.0.0.1:10040,
        reject_invalid_hostname,
        reject_non_fqdn_sender,
        reject_non_fqdn_recipient,
        reject_unknown_sender_domain,
        reject_unknown_recipient_domain,
        reject_unauth_pipelining,
        permit_mynetworks,
        check_recipient_access hash:/usr/local/etc/postfix/tempfail,
        reject_unauth_destination,
        reject_unverified_recipient
        permit

Reply | Threaded
Open this post in threaded view
|

Re: Log Messages

Viktor Dukhovni


> On May 23, 2018, at 4:10 PM, Doug Hardie <[hidden email]> wrote:
>
> I would think that cache would be cleared with a restart.

No.  The verification cache survives restart.  This is intentional.

>  Vmail_alias is dated 28 Apr. That's almost 2 months ago.

In this version of the multiverse Apr/28 is 3.5 weeks ago. :-)
The relevant parameters are:

  http://www.postfix.org/postconf.5.html#address_verify_positive_expire_time
  http://www.postfix.org/postconf.5.html#address_verify_positive_refresh_time

With the defaults one would expect stale positive entries to go away
after ~7 days...

--
        Viktor.

Reply | Threaded
Open this post in threaded view
|

Re: Log Messages

wa6vvv

> On 23 May 2018, at 13:17, Viktor Dukhovni <[hidden email]> wrote:
>
>
>
>> On May 23, 2018, at 4:10 PM, Doug Hardie <[hidden email]> wrote:
>>
>> I would think that cache would be cleared with a restart.
>
> No.  The verification cache survives restart.  This is intentional.

There sure is a lot to learn about postfix...

>
>> Vmail_alias is dated 28 Apr. That's almost 2 months ago.
>
> In this version of the multiverse Apr/28 is 3.5 weeks ago. :-)

Oops...

> The relevant parameters are:
>
>  http://www.postfix.org/postconf.5.html#address_verify_positive_expire_time
>  http://www.postfix.org/postconf.5.html#address_verify_positive_refresh_time
>
> With the defaults one would expect stale positive entries to go away
> after ~7 days...

I haven't touched those defaults.  I didn't even know they existed till now.  I am going to let this sit for another 3 weeks as I will be on other things and we will see what happens by then.  Thanks for the assistance and information.

>
> --
> Viktor.
>

Reply | Threaded
Open this post in threaded view
|

Re: Log Messages

Viktor Dukhovni
In reply to this post by wa6vvv


> On May 23, 2018, at 4:10 PM, Doug Hardie <[hidden email]> wrote:
>
> incoming_smtpd_restrictions =
>        check_policy_service inet:127.0.0.1:10040,
>        reject_invalid_hostname,
>        reject_non_fqdn_sender,
>        reject_non_fqdn_recipient,
>        reject_unknown_sender_domain,
>        reject_unknown_recipient_domain,
>        reject_unauth_pipelining,
>        permit_mynetworks,
>        check_recipient_access hash:/usr/local/etc/postfix/tempfail,
>        reject_unauth_destination,
>        reject_unverified_recipient
>        permit

It is far from clear why you'd want "reject_unverified_recipient"
here.  Do you have sort of wildcard aliasing or other reason to
expect your recipient validation tables to accept ultimately
invalid recipients?

--
        Viktor.

Reply | Threaded
Open this post in threaded view
|

Re: Log Messages

wa6vvv
> On 23 May 2018, at 13:41, Viktor Dukhovni <[hidden email]> wrote:
>
>
>
>> On May 23, 2018, at 4:10 PM, Doug Hardie <[hidden email]> wrote:
>>
>> incoming_smtpd_restrictions =
>>       check_policy_service inet:127.0.0.1:10040,
>>       reject_invalid_hostname,
>>       reject_non_fqdn_sender,
>>       reject_non_fqdn_recipient,
>>       reject_unknown_sender_domain,
>>       reject_unknown_recipient_domain,
>>       reject_unauth_pipelining,
>>       permit_mynetworks,
>>       check_recipient_access hash:/usr/local/etc/postfix/tempfail,
>>       reject_unauth_destination,
>>       reject_unverified_recipient
>>       permit
>
> It is far from clear why you'd want "reject_unverified_recipient"
> here.  Do you have sort of wildcard aliasing or other reason to
> expect your recipient validation tables to accept ultimately
> invalid recipients?

Reading the Prefix Address Verification Howto madeit seem like it would be useful.  I think I see now how it works.  I don't expect the recipient validation tables to have invalid recipients so I have removed that.

-- Doug