rcpt many connections

[Former user]

my newly installed server is consuming a lot of storage and sending unknown emails? Does anyone know what happens? I noticed many rcpt connections, how do I disable it? https://poste.io/qpsmtpd/rcpt-database

[S B]

What's in the delivery logs? Maybe this will give you a clue to what is being sent.

[S B]

It may also be on an IP which was previously an open relay so bots will be trying to send on it anyway.

It may also be an open relay or a whitelisted IP address sending them?

[Leandro Freire]

Well I really do not know what's happening, the server was recently deploy with portainer in a new vps of the "contabo" (I had no problem with the ip of the account) I realized that it came flooding all the storage, I had not released any ip to send emails without authentication. tbm I will not release the port 22 of the container only those that are in the documentation. Thank you so far.

delivery log file

[Leandro Freire]

and why do not the sent emails appear in the registered accounts? I do not even understand that someone had discovered the password of any of the accounts should appear as sent by the account in question, however and as if it were a mass slave.

[S B]

[e-mail] is sending the emails.

It is likely this is not setup on your system as a user (so will not show under 'Top Users')

Next steps -

(1) Go to "Blacklist/Whitelist" and send a screenshot or tell me what is on there.

(2) Go to 'System Settings' and report what is in "Relay networks"

[Leandro Freire]

[S B]

On System Settings, click the Email Processing tab and tell me if Default SMTP route is setup (do not screenshot your secret key)

[Leandro Freire]

As you can see, I have not configured any exit routes

[S B]

I am sorry, from what we have diagnosed as far as I am aware this should not be allowing email to be sent through relay.

All I can suggest is to check the user/authentication logs. Are the account passwords secure? and is strict header check on?

Maybe others can help with what has been provided so far.

[Leandro Freire]

I thank you very much for your cooperation and for being very helpful, thank you very much. I am really worried about this issue, and a great project would not like to change

[S B]

There should be a user log file (like the delivery one you sent) which will show us if users are connecting or not. (Sorry I don't know where this will be found in the free version)

All I can think is an account has been compromised, and "strict header" check is off, and this is not logged as "usage" (top 10) when sending out in such a way.

Have you checked https://mxtoolbox.com/ to test the diagnostics? Open relay, etc.?

On a side note - Stick with the mail server, we use it in production and it is excellent. You will find the help you need here soon.

[Leandro Freire]

thank you for your nomination, I had not gone through this situation of open relay yet, but it seems that's it. now how to block it? Is it possible to do only with SPF registration?

[SH]

1. shutdown your container first
2. delete data/queue directory

what host system are you using? how are you starting container?

[SH]

also please look into any file at data/log/delivery/conn/../../... and paste it here / or send it to me to [e-mail]

[Leandro Freire]

Hello, I'm using a vps of "contabo", this one with docker-swarm + portainer and traefik in front.

version: '3'

services:
  mailserver:
    environment:
      HTTPS: 'OFF'
    image: analogic/poste.io
    ports:
      - "25:25"
      - "110:110"
      - "143:143" 
      - "587:587"
      - "993:993"
      - "995:995"
    hostname: mail.uniaoestudantil.com.br
    labels:
      - "traefik.docker.network=proxy"
      - "traefik.enable=true"
      - "traefik.frontend.rule=Host:mail.uniaoestudantil.com.br"
      - "traefik.port=80"
      - "traefik.frontend.entryPoints=http,https"
      - "traefik.frontend.redirect.entryPoint=https"
    volumes:
      -  /etc/localtime:/etc/localtime:ro
      -  data:/data
    networks:
      - proxy
    deploy:
      placement:
        constraints: [node.role == manager]
volumes:
  data:
networks: 
  proxy:
    external: true

my ingress is 10.255.0.0 not 10.255.0.2

many conn logs, I'll post soon

[S B]

Just an observation, but this and #469 are both using clustered docker services/containers.

[Leandro Freire]

the curious when blocking 10.255.0.2 I do not receive emails

[SH]

S B: you are right

There is https://github.com/moby/moby/issues/25526 for docker swarm (I suspect that kubernates have similar problem too). Best would be to run container in network=host mode (docker swarm 17+), but it will most likely conflict with traefik. I will asap add patch allowing to move http to different port

[Leandro Freire]

Thank you very much, so far, I have sent the logs to the indicated email

[Riccardo Pomato]

@analogic, unfortunately it has the same problem with or without host mode. Is it possible to close totally the relay? Why it always reply with code 250?

[SH]

@tetus72 please find log of some of latest connection at data/log/delivery/conn.. and send me that to [e-mail] - to your question the only way IP can be relayed is that IP is at relayed addresses or is whitelisted

[Riccardo Pomato]

@analogic I sent already in email this morning.

[S B]

S H is this of any use to you?

https://github.com/tomav/docker-mailserver/issues/487

"as a matter of fact "hostname" parameter and .env config do not work with a docker-compose.yml in swarm mode, because .env file are not supported and the method suggested by Berndinox is a workaround using domain overriding"

and also this looks like they had a similar issue - https://github.com/tomav/docker-mailserver/issues/628

[S B]

Could this be an issue with IPv6? I have just had a thought and checked the MX output for the server above and it returns IPv6 information. Maybe it is not handled, or processed incorrectly?

[Leandro Freire]

@tetus72 Can you tell me if your host has some service running on port 25?

 netstat -tulpn | grep -E -w '25 | 80 | 110 | 143 | 443 | 465 | 587 | 993 | 995' 

[SH]

@sb123 "hostname" is not problem - it is currently used only at installation and is not required at all

please update to 2.0.19 and go to https://<yourserver>/admin/server/connection

[SH]

Closing due lack of response. Feel free to reopen