Re: Toss load-balancer health checks, but BCC everything else (always_bcc, check_sender_access and 'smtpd_delay_reject = yes')

[@lbutlr]

On 11 May 2018, at 09:55, deoren  wrote:
> BCC everything EXCEPT for health check emails generated by our HAProxy 
> load-balancer

Seems it would be much simpler to BCC everything and then discard the few 
messages you don’t want.

-- 
I WILL NOT INSTIGATE REVOLUTION Bart chalkboard Ep. 7G06

Re: real life reasons not to use reject_unknown_client_hostname

[@lbutlr]

On 2018-05-12 (15:55 MDT), Thomas Smith  
wrote:
> 
> The documentation[1] and several e-mails here mention that 
> reject_unknown_client_hostname can reject legitimate e-mails.
> 
> What exactly are these scenarios?

A mail sender doesn't have an A record.

> When do they occur in real life?

Yes. Not a lot, but they do and they tend to be important things that often 
have incompetent mail admin (banks, for example).

> Are there really legitimate mail servers that don't have a reverse DNS record 
> that resolves to their IP?

Yes.

> I would like to know so that I can decide whether I should care and whether I 
> can use this option for my setup.

If you receive mail for anyone else but yourself, you cannot.

warn_if_reject reject_unknown_client_hostname

will log times this would have happened. Try it for a few days and see what is 
logged. Last time I did it, it was a lot of mail that was wanted. Perhaps 
things are better in 2018, but I doubt it.

-- 
"I've had a perfectly wonderful evening. But this wasn't it." - Groucho
Marx

real life reasons not to use reject_unknown_client_hostname

[Thomas Smith]

The documentation[1] and several e-mails here mention that 
reject_unknown_client_hostname can reject legitimate e-mails.


What exactly are these scenarios? When do they occur in real life? Are 
there really legitimate mail servers that don't have a reverse DNS 
record that resolves to their IP?


I would like to know so that I can decide whether I should care and 
whether I can use this option for my setup. I would only use this option 
for port 25 (not submission) and make sure that sasl_authenticated 
clients are exempt from it.


[1]http://www.postfix.org/postconf.5.html#reject_unknown_client_hostname

Thomas

Re: real life reasons not to use reject_unknown_client_hostname

[James]

The documentation[1] and several e-mails here mention that 
reject_unknown_client_hostname can reject legitimate e-mails.


What exactly are these scenarios? When do they occur in real life? Are 
there really legitimate mail servers that don't have a reverse DNS 
record that resolves to their IP?


I would like to know so that I can decide whether I should care and 
whether I can use this option for my setup. I would only use this option 
for port 25 (not submission) and make sure that sasl_authenticated 
clients are exempt from it.


[1]http://www.postfix.org/postconf.5.html#reject_unknown_client_hostname


I use it.  I like it.  But... real world can/will bite you in the ass:

1) DNS lookup failures: stuff *does* break occasionally and there *will* 
be minutes/hours when you reject stuff unintentionally, and


2) the source changes their systems or email provider, or their email 
provider changes their systems, and formerly-working reverse DNS stops 
resolving, for all kinds of reasons: I do encounter this occasionally 
when exchanging email with small local businesses.


Therefore: watch your mail log.  I exchange a very small amount of email 
so it's easy for me to do this.  Your mileage will vary.


--

 - James

Re: real life reasons not to use reject_unknown_client_hostname

[Viktor Dukhovni]

> On May 12, 2018, at 6:45 PM, James  wrote:
> 
> 1) DNS lookup failures: stuff *does* break occasionally and there *will* be 
> minutes/hours when you reject stuff unintentionally,

For the record, when the problem is lost packets, lame delegations,
expired DNSSEC signatures, ... mail will be deferred (4XX error code)
not rejected (5XX).  Only when the DNS definitively returns no
reverse or forward data, or the two don't match with the mail be
rejected by this restriction.  Which still does not make it broadly
safe, but it is not quite so brittle as to hard fail for a few lost
packets or some other transient problem that makes queries fail.

-- 
Viktor.

Re: SASL LOGIN authentication failed

[Viktor Dukhovni]

> On May 13, 2018, at 12:42 AM, @lbutlr  wrote:
> 
> In these log lines, what is "UGFzc3dvcmQ6"?
> 
> May 12 07:52:07 mail submit-tls/smtpd[32670]: warning: 
> vps1590651.vs.webtropia-customer.com[62.141.41.104]: SASL LOGIN 
> authentication failed: UGFzc3dvcmQ6

$ printf "%s\n" $(printf "%s\n" UGFzc3dvcmQ6 | openssl base64 -d)
Password:

-- 
Viktor.

Re: real life reasons not to use reject_unknown_client_hostname

[Bill Cole]

On 12 May 2018, at 18:45 (-0400), James wrote:

The documentation[1] and several e-mails here mention that 
reject_unknown_client_hostname can reject legitimate e-mails.


What exactly are these scenarios? When do they occur in real life? 
Are there really legitimate mail servers that don't have a reverse 
DNS record that resolves to their IP?


I would like to know so that I can decide whether I should care and 
whether I can use this option for my setup. I would only use this 
option for port 25 (not submission) and make sure that 
sasl_authenticated clients are exempt from it.


[1]http://www.postfix.org/postconf.5.html#reject_unknown_client_hostname


I use it.  I like it.  But... real world can/will bite you in the ass:


Yes, it can. Note this Received header from *your* message:


Received: from trackivity.com (unknown [IPv6:2607:f0b0:0:205::2])
(using TLSv1 with cipher ADH-AES256-SHA (256/256 bits))
(No client certificate requested)
by english-breakfast.cloud9.net (Postfix) with ESMTPS id A7ADC33260A
	for ; Sat, 12 May 2018 18:45:26 -0400 
(EDT)


So, it is good that the mail server handling this list does not use 
reject_unknown_client_hostname


--
Bill Cole
b...@scconsult.com or billc...@apache.org
(AKA @grumpybozo and many *@billmail.scconsult.com addresses)
Currently Seeking Steady Work: https://linkedin.com/in/billcole

Re: SASL LOGIN authentication failed

[@lbutlr]

On 2018-05-12 (23:01 MDT), Viktor Dukhovni  wrote:
> 
>> On May 13, 2018, at 12:42 AM, @lbutlr  wrote:
>> 
>> In these log lines, what is "UGFzc3dvcmQ6"?
>> 
>> May 12 07:52:07 mail submit-tls/smtpd[32670]: warning: 
>> vps1590651.vs.webtropia-customer.com[62.141.41.104]: SASL LOGIN 
>> authentication failed: UGFzc3dvcmQ6
> 
> $ printf "%s\n" $(printf "%s\n" UGFzc3dvcmQ6 | openssl base64 -d)
> Password:

So, is that what the morons tried to login with (I have a few others that using 
your snippet decode to "Username:" (VXNlcm5hbWU6), they are trying to login 
with a base64 encode of "Usernae:" or "Password:"?

-- 
You too will get old. And when you do you'll fantasize that when you
were young prices where reasonable, politicians were noble, and children
respected their elders. Respect your elders.

Re: real life reasons not to use reject_unknown_client_hostname

[Bill Cole]

On 12 May 2018, at 17:55 (-0400), Thomas Smith wrote:

The documentation[1] and several e-mails here mention that 
reject_unknown_client_hostname can reject legitimate e-mails.


What exactly are these scenarios? When do they occur in real life? Are 
there really legitimate mail servers that don't have a reverse DNS 
record that resolves to their IP?


Yes. Examples:

1. One of the outbound mail servers for my state government (Michigan, 
USA) has 5 PTR records, 2 of which give names that don't resolve. So, 
40% of the time it would hit reject_unknown_client_hostname.


2. Occasionally, DNS for some of the outbound mail servers for Office365 
goes bad and the reverse names for a subset of them return NXDOMAIN 
temporarily.


--
Bill Cole
b...@scconsult.com or billc...@apache.org
(AKA @grumpybozo and many *@billmail.scconsult.com addresses)
Currently Seeking Steady Work: https://linkedin.com/in/billcole

Re: SASL LOGIN authentication failed

[Durga Prasad Malyala]

Wonderful words to reflect on.. on a Sunday.

You too will get old. And when you do you'll fantasize that when you
were young prices where reasonable, politicians were noble, and children
respected their elders. Respect your elders.

Rgds/DP
9849111010 

Sent from my iPhone. Pls excuse brevity and typos if any. 

> On 13-May-2018, at 10:57 AM, @lbutlr  wrote:
> 
> You too will get old. And when you do you'll fantasize that when you
> were young prices where reasonable, politicians were noble, and children
> respected their elders. Respect your elders.

Re: real life reasons not to use reject_unknown_client_hostname

[James]

I use it.  I like it.  But... real world can/will bite you in the ass:


Yes, it can. Note this Received header from *your* message:


Received: from trackivity.com (unknown [IPv6:2607:f0b0:0:205::2])
(using TLSv1 with cipher ADH-AES256-SHA (256/256 bits))
(No client certificate requested)
by english-breakfast.cloud9.net (Postfix) with ESMTPS id A7ADC33260A
for ; Sat, 12 May 2018 18:45:26 -0400 
(EDT)


So, it is good that the mail server handling this list does not use 
reject_unknown_client_hostname




My DNS server is in fact set up correctly for this, and I have requested 
that reverse DNS be delegated down to it, but that delegation hasn't 
happened yet.


Hardly any traffic that I get is IPv6, and this postfix mailing list 
probably accounts for most of it.


Bottom line: no, it's not perfect, but it currently does what I need, 
and I can reasonably expect that the rest will improve over time.


So this actually makes an excellent example for the subject of this 
thread: "reject_unknown_client_hostname", I use it, I like it, and I 
reliably send and receive all the SMTP email that I feel is necessary. 
Occasionally there are wobbles but it's never been a crisis.  Watch your 
logs.  Your mileage will vary.


--

 - James