milter: the level-2 limit and the client IP list hold for every message

Security fix, outside the inbound antispam feature. Found by its
technical review (Opus, 2026-10-12), reproduced on the test stand
before the fix: over an application's level-2 limit, two MAIL FROM on
one connection were answered 451 and then accepted.

Cause. Postfix introduces a client to a milter once per connection.
The milter library (go-milter 0.4.1, session.go) replaces the milter's
session after any reply that is not "continue" - a refusal, or the
accept that used to end a message. The new session never saw Connect,
so it had no client address, and both checks passed a message without
one: overLimit returned early ("no client IP to key on") and
authIPAllowed did the same. So every message after the first on a
connection, and every MAIL FROM after a refused one, skipped the
level-2 limit and an application's client IP list. In the code since
1.9.0 for the list and longer for the limit.

Fix.
  - build/postfix-config.sh: milter_mail_macros carries {client_addr},
    so the address comes with every MAIL FROM; MailFrom reads it (both
    spellings of IPv6) in the journal milter and the inbound journal
    milter.
  - overLimit no longer asks for a client address: a ceiling is on a
    domain or an application.
  - authIPAllowed refuses an application that has a client IP list when
    no address is known.
  - Body replies "continue" in both milters, which lets the message
    through as "accept" did and keeps the session.

The inbound journal milter had the same cause with a smaller effect:
rows of a connection's later messages had no client address.

In the same file, the checks of INBOUND_ANTISPAM_MILTER and
INBOUND_JOURNAL_MILTER_SOCKET refuse any character outside their set
first: a glob's "*" matched anything after the first characters.

Tests: a session that never saw Connect is judged by the macro, a
listed and an unlisted address, no address, not an address; the limit
with no client address; the inbound milter answers only "continue".
test/e2e sends two MAIL FROM on one connection over the limit and
wants both refused.

Checked on the test server: e2e red before the fix on exactly that
check, green after; go vet ./... ok, go test ./... ok (22 packages).

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>

internal/milter/authip.go

@@ -8,11 +8,12 @@ import (
 )
 
 // authIPAllowed reports whether the authenticated application may submit from
-// the connecting client IP. When the application has no IP restriction, or the
-// client IP is not known, the check passes. Store errors are fail-open (see
-// overLimit).
+// the connecting client IP. When the application has no IP restriction the
+// check passes. When it has one and the client's address is not known, the
+// check fails: an address list that an unknown address satisfies is no list.
+// Store errors are fail-open (see overLimit).
 func (s *session) authIPAllowed() bool {
-	if s.login == "" || s.clientIP == "" {
+	if s.login == "" {
 		return true
 	}
 	a, err := s.rec.ApplicationByLogin(s.login)
@@ -26,6 +27,10 @@ func (s *session) authIPAllowed() bool {
 	if a.AllowsAuthFromIP(s.clientIP) {
 		return true
 	}
+	if s.clientIP == "" {
+		log.Printf("journal-milter: application %q refused — its client IPs are restricted and Postfix gave no client address", s.login)
+		return false
+	}
 	log.Printf("journal-milter: application %q refused from %s — client IP not allowed", s.login, s.clientIP)
 	return false
 }