Good. Check those logs again. There you should find an explanation 
.
I have a strong suspicion in IPFireâs âLOG Mails,â there are only the logs of the mails that IPFire sends.
I donât know if you find the NAS mail logs there as well.
So check other entries as well possibly. âFiddle around with it a bitâ.
NAS LOGs might also come in handy .
That IPFire only logs its own sent mails may of course be true.
The NAS logs only say something like âmail sent successfullyâ
1 Like
Just to be sure: It is your NAS that has to send the emails containing the records, right?
That is the case. That is the system logs for packages running on IPFire.
It was mentioned in an earlier post that telnet had failed with an error. What error message did you get.
I tested a telnet connection to the gmail smtp server and that worked fine. It gave me messages up to STARTTLS at which point it would get encrypted but it showed that the gmail smtp server was accepting connections.
The same must be happening with your mail server on your web server system.
Here is my telnet communication sequence.
telnet smtp.gmail.com 587
Trying 142.250.102.108âŚ
Connected to smtp.gmail.com.
Escape character is â^]â.
220 smtp.gmail.com ESMTP e11-20020a170906080b00b008ef42f9cf48sm1021171ejd.82 - gsmtp
At this point the server is waiting for some communication so I did an ehlo message to the smtp server
ehlo smtp.gmail.com
250-smtp.gmail.com at your service, [xxx.xxx.xxx.xxx]
250-SIZE 35882577
250-8BITMIME
250-STARTTLS
250-ENHANCEDSTATUSCODES
250-PIPELINING
250-CHUNKING
250 SMTPUTF8
You can see the successful STARTTLS message . As encrypted communication would be needed from this point I just entered quit and the connection was closed.
quit
221 2.0.0 closing connection e11-20020a170906080b00b008ef42f9cf48sm1021171ejd.82 - gsmtp
Connection closed by foreign host.
Where in the above sequence of steps is your telnet error occurring and what is the error?
1 Like
yeah, well that was GMAIL, that is not the intended e-mail server.
Hang on, let me check if telnet is even possible towards that server, it is on my webhost, I do not handle it, and I guess I better keep them in the loop so they donât think we are doing âthingsâ.
1 Like
Could it be that the webhost has banned you?
No. It is my Webhost that I pay for and even if sometimes an IP may get blocked due to to many login attempts and we also have some additional protection in place, this is not it.
1 Like
The messages from connections to mail servers running with port 587 are standard so the example with gmail was to show the messages with an actual connection from my green net to the internet and all mail servers will work with telnet up to the STARTTLS stage as telnet uses the same communication protocol as the mail servers do.
In post 27 you wrote
which is why I thought you had already tried telnet and had got an error message. If I have misunderstood your intention, my apologies.
The only reason IPFire would be blocking port 587 going out would be if you had written a firewall rule to do that.
The only other way would be if you had changed the default for traffic going from green to red from ACCEPT to DROP or REJECT but in that case ALL traffic to everything would not work unless specific firewall rules were written for desired traffic. So browsing would also not work unless rules were written to allow http and https to go out to red.
There is no default blocking by IPFire of port 587 traffic going out to the internet.
It is also mentioned in post 33 that a TrueNAS server running with the same settings is able to send emails to your webhost successfully so that indicates port 587 must be working going out to the internet and that the webhost is accepting emails from your IP.
The above would make me look at the settings of the ASUSTOR NAS to make 100% sure everything is correct there.
Beyond that I am also running out of ideas.
2 Likes
@bonnietwin I, too, had considered several of these aspects. Iâm running out of ideas myself 
.
It seems to me the only remedy for now.
We have the same ideas 
.
@sec-con Couldnât find any info about this 
: Is your ipFire default behavior of the firewall set to âblockedâ or âallowedâ? If blocked you shld have to write some FW-rules to have your NAS open for sending mails.
Webhost are checking their logs now, to see if anything comes OUT from my Network, via IPFire, but do not reach my Inbox, for some reason.
There is nothing that can be set âwrongâ in the NAS, I posted a screenie of the interface a bit up and I have a screenshot of working settings.
Iâll just put it here. This is a screenshot of a working conf from⌠I donât know, years ago. Been same ever since.
Thatâs it.
I have checked all the logs I can think of on the NAS, on the IPFire.
Also checked the Spamhaus and Shodan logs for anything, but no. There are no URL filters, not anything worth mentioning in System logs.
WOI send me successful logs:
and that is to the same mail server, even if a slightly different address.
I am a bit puzzled by a couple of syslog entries thoug, but that could be something different.
07:14:21 dma: can not open auth file `/var/ipfire/dma/auth.conf': Permission denied
08:24:21 dma: can not open auth file `/var/ipfire/dma/auth.conf': Permission denied
16:50:19 dma[6034a4]: new mail from user=root uid=8 envelope_from=<security@conram.it>
16:50:19 dma[6034a4]: mail to=<security@conram.it> queued as 6034a4.d04230
16:50:19 dma[6034a4.d04230]: <security@conram.it> trying delivery
16:50:19 dma[6034a4.d04230]: using smarthost (ns2.inleed.net:587)
16:50:19 dma[6034a4.d04230]: trying remote delivery to ns2.inleed.net [2001:67c:750::3] pref 0
16:50:19 dma[6034a4.d04230]: connect to ns2.inleed.net [2001:67c:750::3] failed: Cannot assign requested addr ess
16:50:19 dma[6034a4.d04230]: trying remote delivery to ns2.inleed.net [185.189.49.215] pref 0
16:50:19 dma[6034a4.d04230]: Server greeting successfully completed
16:50:19 dma[6034a4.d04230]: Server supports STARTTLS
16:50:19 dma[6034a4.d04230]: Server supports LOGIN authentication
16:50:19 dma[6034a4.d04230]: SSL initialization successful
16:50:19 dma[6034a4.d04230]: Server greeting successfully completed
16:50:19 dma[6034a4.d04230]: Server does not support STARTTLS
16:50:19 dma[6034a4.d04230]: Server supports LOGIN authentication
16:50:19 dma[6034a4.d04230]: using SMTP authentication for user security@conram.it
16:50:20 dma[6034a4.d04230]: <security@conram.it> delivery successful
16:55:01 dma[6034a4]: new mail from user=root uid=8 envelope_from=<security@conram.it>
16:55:01 dma[6034a4]: mail to=<security@conram.it> queued as 6034a4.51a230
16:55:01 dma[6034a4.51a230]: <security@conram.it> trying delivery
16:55:01 dma[6034a4.51a230]: using smarthost (ns2.inleed.net:587)
16:55:01 dma[6034a4.51a230]: trying remote delivery to ns2.inleed.net [2001:67c:750::3] pref 0
16:55:01 dma[6034a4.51a230]: connect to ns2.inleed.net [2001:67c:750::3] failed: Cannot assign requested addr ess
16:55:01 dma[6034a4.51a230]: trying remote delivery to ns2.inleed.net [185.189.49.215] pref 0
16:55:01 dma[6034a4.51a230]: Server greeting successfully completed
16:55:01 dma[6034a4.51a230]: Server supports STARTTLS
16:55:01 dma[6034a4.51a230]: Server supports LOGIN authentication
16:55:01 dma[6034a4.51a230]: SSL initialization successful
16:55:01 dma[6034a4.51a230]: Server greeting successfully completed
16:55:01 dma[6034a4.51a230]: Server does not support STARTTLS
16:55:01 dma[6034a4.51a230]: Server supports LOGIN authentication
16:55:01 dma[6034a4.51a230]: using SMTP authentication for user security@conram.it
16:55:01 dma[6034a4.51a230]: <security@conram.it> delivery successful
Feel free to check.
âŚ
OK, reply from webhost. They had a conf hickup. Wouldnât tell me what though.
SOLVED
I apologize for taking time from you guys.
1 Like
For me no reason to apologize .
I had thought of a webhost problem.
Iâm glad 
.