Re: Clients Sending Phantom Email

[Matus UHLAR - fantomas]

On 28.04.21 09:28, Asai wrote:
We are getting reports, more and more, of email clients (Type App, Mac 
Mail, iOS Mail) that seem to send email, and show that the email has 
been sent on the client, but the mail server has no record of email 
ever reaching the SMTP service, nor does it even seem that the client 
is connecting to the server.


ask for their clients' logs.  Ask for screenshot of their setup.  They
apparently don't use your server or their connections are redirected.

--
Matus UHLAR - fantomas, uh...@fantomas.sk ; http://www.fantomas.sk/
Warning: I wish NOT to receive e-mail advertising to this address.
Varovanie: na tuto adresu chcem NEDOSTAVAT akukolvek reklamnu postu.
You have the right to remain silent. Anything you say will be misquoted,
then used against you.

Re: use relay host on direct connection failure

[Matus UHLAR - fantomas]

On 28.04.21 22:24, sashk wrote:

  They respond with following code on connect:
   
  (host mxb-00306701.gslb.pphosted.com[67.231.145.123] refused to talk to
  me: 554 Blocked - see
  [1]https://ipcheck.proofpoint.com/?ip=XXX.XXX.XXX.XXX


either you are blacklisted or they don't provide the service.

123.145.231.67.in-addr.arpa domain name pointer mx0a-00306701.pphosted.com.

Are you sure it's their outgoing mailserver, not incoming one?


  $ nc -v 67.231.145.123 25
  Connection to 67.231.145.123 25 port [tcp/smtp] succeeded!
  554 Blocked - see [2]https://ipcheck.proofpoint.com/?ip=XXX.XXX.XXX.XXX


are you sure you are supposed to send mail to outside through port 25?

--
Matus UHLAR - fantomas, uh...@fantomas.sk ; http://www.fantomas.sk/
Warning: I wish NOT to receive e-mail advertising to this address.
Varovanie: na tuto adresu chcem NEDOSTAVAT akukolvek reklamnu postu.
Fighting for peace is like fucking for virginity...

Re: Postfix shows unknown instead of resolved hostname

[Matus UHLAR - fantomas]

On 29.04.21 06:25, Fourhundred Thecat wrote:

Postfix does not show hostname for a connecting IP address, when the
hostname does not have reverse lookup:

Example from my log:

 warning: hostname zg-0416b-243.stretchoid.com does not resolve to
address 192.241.220.141: Name or service not known
 connect from unknown[192.241.220.141]
 timeout after EHLO from unknown[192.241.220.141]
 disconnect from unknown[192.241.220.141] ehlo=1 commands=1



It is a good thing that postfix warns me that hostname does not resolve
back to the IP, but why does it show:

 connect from unknown[192.241.220.141]

instead of

 connect from zg-0416b-243.stretchoid.com[192.241.220.141]

The IP has DNS record, so even when reverse does not work, I would like
to see the hostname that is connecting

can this be configured?


no. There's no poing in trusting reverse lookup if it's not
forward-confirmed.
Anyone can poing their reverse DNS to any domain they don't own.

Get proper reverse/forward name, possibly not generic.

--
Matus UHLAR - fantomas, uh...@fantomas.sk ; http://www.fantomas.sk/
Warning: I wish NOT to receive e-mail advertising to this address.
Varovanie: na tuto adresu chcem NEDOSTAVAT akukolvek reklamnu postu.
LSD will make your ECS screen display 16.7 million colors

Re: Want to configure domain localhost to support root

[Nick Tait]

On 27/04/21 3:38 am, Michael White wrote:
So updating mailer.conf got rid of sendmail.  So now I need to move to 
the next step which is to understand what the resulting messages are 
telling me:


Apr 26 11:22:57 white-home postfix/pickup[23008]: DE94263846: uid=1002 
from=
Apr 26 11:22:57 white-home postfix/cleanup[23025]: DE94263846: 
message-id=<20210426152257.de94263...@mail.white-home.net 
>
Apr 26 11:22:57 white-home postfix/qmgr[23009]: DE94263846: 
from=mailto:x...@mail.white-home.net>>, 
size=309, nrcpt=1 (queue active)
Apr 26 11:22:57 white-home postfix/virtual[23029]: DE94263846: 
to=, relay=virtual, delay=0.09, 
delays=0.04/0.02/0/0.02, dsn=5.1.1, status=bounced (unknown user: 
"@localhost")
Apr 26 11:22:57 white-home postfix/cleanup[23025]: F0B4C63883: 
message-id=<20210426152257.f0b4c63...@mail.white-home.net 
>
Apr 26 11:22:57 white-home postfix/bounce[23031]: DE94263846: sender 
non-delivery notification: F0B4C63883
Apr 26 11:22:57 white-home postfix/qmgr[23009]: F0B4C63883: from=<>, 
size=2215, nrcpt=1 (queue active)

Apr 26 11:22:57 white-home postfix/qmgr[23009]: DE94263846: removed
Apr 26 11:22:57 white-home postfix/virtual[23029]: F0B4C63883: 
to=mailto:x...@mail.white-home.net>>, 
relay=virtual, delay=0.01, delays=0/0/0/0, dsn=5.1.1, status=bounced 
(unknown user: "x...@mail.white-home.net 
")

Apr 26 11:22:57 white-home postfix/qmgr[23009]: F0B4C63883: removed

Now I am at a loss as to how to mix real and virtual users.  I am 
using postfixadmin to manage my virtual user database and it does not 
allow me to add a localhost domain as I mentioned with my initial 
post.  Agin I tried ‘localhost.’ thinking that might cover the ‘x.x’ edit.


It looks like what you need is something to alias @localhost to 
x...@mail.white-home.net? Or perhaps what would be more useful is 
aliasing @/anything/ to x...@mail.white-home.net? If so I'd suggest 
having a look at virtual_alias_maps?


I'm thinking something along the lines of...

In main.cf:

   virtual_alias_domains =
   virtual_alias_maps = hash:/etc/postfix/virtual

In /etc/postfix/virtual:

    x...@mail.white-home.net

(And don't forget to run "postmap hash:/etc/postfix/virtual".)

I seem to recall there is a bit more to this, including checking that 
myorigin is set, but hopefully that will get you heading in the right 
direction?


Nick.

Re: Postfix shows unknown instead of resolved hostname

[Fourhundred Thecat]

> On 2021-04-29 10:25, Matus UHLAR - fantomas wrote:

On 29.04.21 06:25, Fourhundred Thecat wrote:

Postfix does not show hostname for a connecting IP address, when the
hostname does not have reverse lookup:

Example from my log:

 warning: hostname zg-0416b-243.stretchoid.com does not resolve to
address 192.241.220.141: Name or service not known
 connect from unknown[192.241.220.141]
 timeout after EHLO from unknown[192.241.220.141]
 disconnect from unknown[192.241.220.141] ehlo=1 commands=1



It is a good thing that postfix warns me that hostname does not resolve
back to the IP, but why does it show:

 connect from unknown[192.241.220.141]

instead of

 connect from zg-0416b-243.stretchoid.com[192.241.220.141]

The IP has DNS record, so even when reverse does not work, I would like
to see the hostname that is connecting

can this be configured?


no. There's no poing in trusting reverse lookup if it's not
forward-confirmed.
Anyone can poing their reverse DNS to any domain they don't own.


when I query the IP with "host" command, I get:

$ host 192.241.220.141
141.220.241.192.in-addr.arpa domain name pointer
zg-0416b-243.stretchoid.com.

same when I do it in my python script using gethostbyaddr()

Can't postfix be configured to do it similarly ?



Get proper reverse/forward name, possibly not generic.


what do you mean? I don't control these IP addresses.
These are just connecting to my mail server

Re: Postfix shows unknown instead of resolved hostname

[Fourhundred Thecat]

> On 2021-04-29 08:00, lists wrote:

Sorry for the top posting.
http://www.stretchoid.com/
has a way to opt out. Unfortunately they want you to give them your IP space 
rather than the other way around. They use a floating IP scheme and can't 
easily be blocked.


stretchoid was just an example.
I need a generic solution.

Re: Postfix shows unknown instead of resolved hostname

[Matus UHLAR - fantomas]

On 29.04.21 06:25, Fourhundred Thecat wrote:

Postfix does not show hostname for a connecting IP address, when the
hostname does not have reverse lookup:

Example from my log:

 warning: hostname zg-0416b-243.stretchoid.com does not resolve to
address 192.241.220.141: Name or service not known
 connect from unknown[192.241.220.141]
 timeout after EHLO from unknown[192.241.220.141]
 disconnect from unknown[192.241.220.141] ehlo=1 commands=1



It is a good thing that postfix warns me that hostname does not resolve
back to the IP, but why does it show:

 connect from unknown[192.241.220.141]

instead of

 connect from zg-0416b-243.stretchoid.com[192.241.220.141]

The IP has DNS record, so even when reverse does not work, I would like
to see the hostname that is connecting

can this be configured?



On 2021-04-29 10:25, Matus UHLAR - fantomas wrote:
no. There's no poing in trusting reverse lookup if it's not
forward-confirmed.
Anyone can poing their reverse DNS to any domain they don't own.


On 29.04.21 14:04, Fourhundred Thecat wrote:

when I query the IP with "host" command, I get:

$ host 192.241.220.141
141.220.241.192.in-addr.arpa domain name pointer
zg-0416b-243.stretchoid.com.

same when I do it in my python script using gethostbyaddr()

Can't postfix be configured to do it similarly ?


Once again:
The result of reverse resolution will NOT be used, unless it's verified by
forward resolution.

Anyone can point their reverse DNS to any hostname and you should NOT use it, if
the hostname does not map back to that IP address.

it will be logged, but that's all.


Get proper reverse/forward name, possibly not generic.


what do you mean? I don't control these IP addresses.
These are just connecting to my mail server


you can turn off referse lookup if it annoys you.

Nobody serious will use random unconfirmed reverse hostnames.

--
Matus UHLAR - fantomas, uh...@fantomas.sk ; http://www.fantomas.sk/
Warning: I wish NOT to receive e-mail advertising to this address.
Varovanie: na tuto adresu chcem NEDOSTAVAT akukolvek reklamnu postu.
Emacs is a complicated operating system without good text editor.

Re: Clients Sending Phantom Email

[@lbutlr]

On 28 Apr 2021, at 10:28, Asai  wrote:
> We are getting reports, more and more, of email clients (Type App, Mac Mail, 
> iOS Mail) that seem to send email, and show that the email has been sent on 
> the client, but the mail server has no record of email ever reaching the SMTP 
> service, nor does it even seem that the client is connecting to the server.

First guess is they are sending through a different server. Mac/iOS are pretty 
good about trying over servers if one fails.

> Can someone advise as to what area of debugging we can turn on? There's a lot 
> of info in debugging, and we can't turn it all on at once, so we could use 
> some specifics.

If you do not see them connecting to you, no amount of logging or debugging 
will change that.

-- 
Mos Eisley spaceport. You will never find a more wretched hive of
scum and villainy. We must be cautious.

Re: Make rule to install posttls-finger?

[Wietse Venema]

Paul Menzel:
> Dear Postfix users,
> 
> 
> I couldn?t find a Make rule to install `posttls-finger`? Did I overlook 
> something, or would I need to copy it manually?

There is no such rule, because Postfix test programs are not supported.
Supported programns are protected by backwards and forwards compatibiliy.

Wietse

Re: Clients Sending Phantom Email

[Aban Dokht]

Asai wrote:


Can someone advise as to what area of debugging we can turn on? There's a lot 
of info in debugging, and we can't turn it all on at once, so we could use some 
specifics.


Perhaps setting up SPF + DMARC RUF will help you to identify those systems.


Regards
Aban

--
 Aban Dokht   aban.do...@abando.de
--

Re: Postfix shows unknown instead of resolved hostname

[Jaroslaw Rafa]

Dnia 29.04.2021 o godz. 14:34:15 Matus UHLAR - fantomas pisze:
> 
> Once again:
> The result of reverse resolution will NOT be used, unless it's verified by
> forward resolution.

>From the times I was using sendmail, I remember that in case when
forward/reverse DNS didn't match, sendmail logged something like

unknown (reverse.dns.hostname) [ip.ad.dr.ess]

and when they match, it logged just

reverse.dns.hostname [ip.ad.dr.ess]

I guess the OP would be satisfied if Postfix did something similar?
-- 
Regards,
   Jaroslaw Rafa
   r...@rafa.eu.org
--
"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."

Re: Clients Sending Phantom Email

[Tom Hendrikx]

On 28-04-2021 22:41, Wietse Venema wrote:

Asai:

Greetings,

We are getting reports, more and more, of email clients (Type App, Mac
Mail, iOS Mail) that seem to send email, and show that the email has
been sent on the client, but the mail server has no record of email ever
reaching the SMTP service, nor does it even seem that the client is
connecting to the server.


This means that client systems are compromised with malware
that sends email directly to the outside world, bypassing
your mail server.

To stop these, block outbound port 25 on your firewall for all
systems except your mail server.



The OP has not specified whether the intended recipient ever receives 
the message, only that the sender thinks it's sent, and that the 
expected MSA doesn't see the message in transfer.


In the past, I've also seen desktop malware scanners that setup a local 
SMTP proxy for all outgoing email. It might be that the Mail client 
sends the message successfully to the proxy, but the proxy sends it to 
/dev/null and doesn't inform the desktop user properly.


Kind regards,
Tom

Re: Postfix shows unknown instead of resolved hostname

[Wietse Venema]

Jaroslaw Rafa:
> Dnia 29.04.2021 o godz. 14:34:15 Matus UHLAR - fantomas pisze:
> > 
> > Once again:
> > The result of reverse resolution will NOT be used, unless it's verified by
> > forward resolution.
> 
> >From the times I was using sendmail, I remember that in case when
> forward/reverse DNS didn't match, sendmail logged something like
> 
> unknown (reverse.dns.hostname) [ip.ad.dr.ess]

I thought that sendmail logs the HELO 

unknown (HELO-or-EHLOname [ipaddress])

Wietse

Re: Postfix shows unknown instead of resolved hostname

[Jaroslaw Rafa]

Dnia 29.04.2021 o godz. 11:27:28 Wietse Venema pisze:
> > >From the times I was using sendmail, I remember that in case when
> > forward/reverse DNS didn't match, sendmail logged something like
> > 
> > unknown (reverse.dns.hostname) [ip.ad.dr.ess]
> 
> I thought that sendmail logs the HELO 
> 
> unknown (HELO-or-EHLOname [ipaddress])

Maybe you're right, I don't remember too well, as I stopped using sendmail
quite long time ago. However, I'm sure it also logged non-matching DNS in
somehow similar way...
-- 
Regards,
   Jaroslaw Rafa
   r...@rafa.eu.org
--
"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."

Re: Postfix shows unknown instead of resolved hostname

[Wietse Venema]

Wietse Venema:
> Jaroslaw Rafa:
> > Dnia 29.04.2021 o godz. 14:34:15 Matus UHLAR - fantomas pisze:
> > > 
> > > Once again:
> > > The result of reverse resolution will NOT be used, unless it's verified by
> > > forward resolution.
> > 
> > >From the times I was using sendmail, I remember that in case when
> > forward/reverse DNS didn't match, sendmail logged something like
> > 
> > unknown (reverse.dns.hostname) [ip.ad.dr.ess]
> 
> I thought that sendmail logs the HELO 
> 
> unknown (HELO-or-EHLOname [ipaddress])

Postfix does this:

helo-or-ehlo (unknown [ipaddress]).

Which is was inspired by Sendmail.

Wietse

Code:
out_fprintf(out_stream, REC_TYPE_NORM,
"Received: from %s (%s [%s])",
state->helo_name ? state->helo_name : state->name,
state->name, state->rfc_addr);

Postfix stable release 3.6.0

[Wietse Venema]

Postfix stable release 3.6.0 is available. This ends the support
for legacy release Postfix 3.2.

The main changes are below. See the RELEASE_NOTES file for further
details.

Incompatible changes:

  * This release requires "postfix stop" before updating, or before
backing out to an earlier release, because some internal protocols
have changed. Otherwise, long-running daemons (pickup, qmgr,
verify, tlsproxy, postscreen) may fail to communicate with the
rest of Postfix, causing mail delivery delays until Postfix is
restarted.

  * Respectful logging. Postfix version 3.6 deprecates terminology
that implies white is better than black. Instead, Postfix prefers
'allowlist', 'denylist', and variations on those words. This
change affects Postfix documentation, and postscreen parameters
and logging.

To keep the old postscreen logging set "respectful_logging =
no" in main.cf before setting "compatibility_level = 3.6".  In
any case, the old postscreen parameter names will keep working
as before.

Other changes:

  * The minimum supported OpenSSL version is 1.1.1, which will reach
the end of life by 2023-09-11. Postfix 3.6 is expected to reach
the end of support in 2025. Until then, Postfix will be updated
as needed for compatibility with OpenSSL.

The default fingerprint digest has changed from md5 to sha256
(Postfix 3.6 with compatibility_level >= 3.6). With a lower
compatibility_level setting, Postfix defaults to using md5, and
logs a warning when a Postfix configuration specifies no explicit
digest type.

The export-grade Diffie-Hellman key exchange is no longer
supported, and the tlsproxy_tls_dh512_param_file parameter is
ignored,

  * Better error messages when someone configures an incorrect
program in master.cf. To recognize such mistakes, every Postfix
internal service, including the postdrop command, announces the
name of its protocol before doing any other I/O, and every
Postfix client program, including the Postfix sendmail command,
will verify that the protocol name matches what it expects.

  * Fine-grained control over the envelope sender address for
submission with the Postfix sendmail (or postdrop) commands.

Example:

/etc/postfix/main.cf:
# Allow root and postfix full control, anyone else can only
# send mail as themselves. Use "uid:" followed by the numerical
# UID when the UID has no entry in the UNIX password file.
local_login_sender_maps =
inline:{ { root = *}, { postfix = * } },
pcre:/etc/postfix/login_senders

/etc/postfix/login_senders:
   # Allow both the bare username and the user@domain forms.
/(.+)/ $1 $1...@example.com

  * Threaded bounces. This allows mail readers to present a
non-delivery, delayed delivery, or successful delivery notification
in the same email thread as the original message.

Unfortunately, this also makes it easy for users to mistakenly
delete the whole email thread (all related messages), instead
of deleting only the delivery status notification.

To enable, specify "enable_threaded_bounces = yes".

  * Postfix by default no longer uses the services(5) database to
look up the TCP ports for SMTP and LMTP services. Instead, this
information is configured with the new known_tcp_ports configuration
parameter (default: lmtp=24, smtp=25, smtps=submissions=465,
submission=587). When a service is not specified in known_tcp_ports,
Postfix will still query the services(5) database.

  * Starting with Postfix version 3.6, the compatibility level is
"3.6". In future Postfix releases, the compatibility level will
be the Postfix version that introduced the last incompatible
change. The level is formatted as 'major.minor.patch', where
'patch' is usually omitted and defaults to zero. Earlier
compatibility levels are 0, 1 and 2.

This also introduces main.cf and master.cf support for the
<=level, < level, and other operators to compare compatibility
levels. With the standard <=, <, etc. operators, compatibility
level 3.10 would be less than 3.9, which is undesirable.

You can find the updated Postfix source code at the mirrors listed
at http://www.postfix.org/.

Wietse

OpenDMARC 1.4.1 Released

[Dan Mahoney (Gushi)]

Hey there,

A cross post because there's enough dmarc discussion to be relevant.

We've just released OpenDMARC 1.4.1 over at
https://github.com/trusteddomainproject/OpenDMARC

While the delta between 1.4.0 and 1.4.1 may seem minor if one goes by the 
version numbers, it's actually a pretty solid release, including:


* Addressing of four CVEs (all that were present at this time).

* Compatibility with more recent versions of Autoconf like 2.70

* Addresses to fix build issues on several BSD and linux platforms.

* Inclusion of a new feature to keep messages from being quarantined.

* Many fixes to our own internal SPF implementation.

* Addition of more unit tests and filter tests.

* Fixes of many (but not yet all) compiler warnings.

* Many documentation fixes to sigil that the project is alive, and has
  moved on from Sourceforge to GitHub.

(This is just a quick summary, please do check out the full release 
notes).


We have announced this to our own mailing lists as well, and work is 
underway to modernize the MTA and mailing lists to something more recent. 
(This is partially why I'm crossposting -- some have complained of ssl 
issues with those.)


We'll likely be turning our attention to OpenDKIM next, as it's also long 
due for a maintenance release.  I'd like to thank the people on this 
mailing list for your lively discussion and feedback, and tolerance of the 
occasional off-topic post.


Stay safe out there,

-Dan Mahoney
For the Trusted Domain project

--

Dan Mahoney
Techie,  Sysadmin,  WebGeek
Gushi on efnet/undernet IRC
FB:  fb.com/DanielMahoneyIV
LI:   linkedin.com/in/gushi
Site:  http://www.gushi.org
---