Sender verification for username@hostname style addresses

classic Classic list List threaded Threaded
3 messages Options
Reply | Threaded
Open this post in threaded view
|

Sender verification for username@hostname style addresses

"Snel.com - Yavuz" Aydın
Hi all,

We have a setup where we have a relay server which in turn sends all
received mails through to another relay server (from a known anti-spam
vendor). We use Postfix 3.4.5 on Debian 10.

The important parts about our setup:

smtpd_sender_restrictions = reject_unknown_sender_domain
reject_unverified_sender permit_mynetworks
relayhost = [smtp.antispamcloud.com]:587

Since smtp.antispamcloud.com has a very strict sender verification
process we want to reject the same mails. Hence we enabled
reject_unverified_sender. It looks like our Postfix server accepts mail which has a sender www-data@hostname while smtp.antispamcloud.com reject the same mail for a specific hostname. That specific hostname (a FQDN) is behind a CloudFlare DNS proxy so I understand why smtp.antispamcloud.com can't verify the sender. What I don't understand  is why Postfix accepts the mail. The hostname does not have MX records assigned (the parent domain does and the parent domain has a catch-all account).

I think Postfix checks the parent domain or POstfix just connects back
to the connecting mailserver to do the check (which would pass).

My questions:
1. How do I debug this?
2. Does Postfix check the parent domain when doing sender verification?
If yes, how do I stop that behaviour?
3. Does Postfix check the connecting mailserver when doing sender
verification? If yes, how do I stop that behaviour?

Thanks!

--
Met vriendelijke groet,

Yavuz Aydın
Snel.com


Reply | Threaded
Open this post in threaded view
|

Re: Sender verification for username@hostname style addresses

Jaroslaw Rafa
Dnia 12.11.2019 o godz. 10:20:01 Snel.com - Yavuz Aydın pisze:
> reject_unverified_sender. It looks like our Postfix server accepts mail
> which has a sender www-data@hostname while smtp.antispamcloud.com reject
> the same mail for a specific hostname.  That specific hostname (a FQDN) is
> behind a CloudFlare DNS proxy so I understand why smtp.antispamcloud.com
> can't verify the sender.  What I don't understand is why Postfix accepts
> the mail.  The hostname does not have MX records assigned (the parent
> domain does and the parent domain has a catch-all account).

If you have an address username@domain and you want to send mail to that
address (and Postfix sender verification works just like that - attempts to
send mail to the address, and if SMTP transaction is accepted, cancels the
attempt and backs out before DATA stage), and "domain" does not have a MX
record, then, by RFC, A or AAAA records are checked for "domain". There is
no obligation to have a MX record defined for hostname to have mail
delivered to that address.

Maybe "smtp.antispamcloud.com" simply violates the RFC by rejecting domains
that don't have an MX record? (and Postfix does not)
--
Regards,
   Jaroslaw Rafa
   [hidden email]
--
"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."
Reply | Threaded
Open this post in threaded view
|

Re: Sender verification for username@hostname style addresses

Wietse Venema
In reply to this post by "Snel.com - Yavuz" Aydın
Snel.com - Yavuz Ayd?n:
> I think Postfix checks the parent domain or POstfix just connects back
> to the connecting mailserver to do the check (which would pass).

No, that would be immensely stupid, especially if the email address
is not remote. Postfix probes follow the same path that ordinary
email would follow, including transport_maps, MX resolution, or
local delivery. It uses the same delivery processes for probes and
ordinary email. Some might consider that a revolutionary concept,
but it makes the result more realistic.

> My questions:
> 1. How do I debug this?

Postfix logs every transaction including probes. DO NOT turn on
verbose (debug) logging. That just makes the information you need
harder to find.

        Wietse