Spam Folders?

[redwoodhead]

I was checking my disk space usage and (just now) noticed that /mail/cur and /mail/new have a combined total of about 40MB in them. I ftp'd a few files over to my machine and looked at them in a text editor. It seems they are all spam. I have NOT enabled SpamAssassin and did not expect to find spam folders with contents. It also seems there are separate "cur" and "new" folders for each of the email addresses I have created, but those are empty.

 

Just wondered if you would shed a bit of light on this. I take it I need to manually empty these folders occasionally.

 

Thanks

[TCH-Dick]

These directories (tmp, new, and cur) are where messages are processed/stored by the system and should not be removed.

tmp - used during the delivery process

new - where mail is stored until you read it or fetch to your local machine

cur - where viewed emails are stored if you do not fetch them to your local machine

 

The directories you are seeing are most likely for your default address, this is the email account where unrouted email (mail sent to an invalid email address) is stored. You should log in to cPanel and set your Default Address to :fail: and these emails will no longer be accepted or stored on you account.

[redwoodhead]

These directories (tmp, new, and cur) are where messages are processed/stored by the system and should not be removed.

tmp - used during the delivery process

new - where mail is stored until you read it or fetch to your local machine

cur - where viewed emails are stored if you do not fetch them to your local machine

 

The directories you are seeing are most likely for your default address, this is the email account where unrouted email (mail sent to an invalid email address) is stored. You should log in to cPanel and set your Default Address to :fail: and these emails will no longer be accepted or stored on you account.

That makes sense!

 

But when checking this setting I see that my current setting is already ":fail". But I also see there is an option (under "Advanced settings") to "Discard (Not recommended)" (The current setting is actually "Discard with error to sender (at SMTP time)", which seems to be an option that is interpreted as ":fail".) So, I will give the "not recommended" option a go. (I can't immediately see any advantage in accepting and storing email from anybody who doesn't know what my valid email addresses are!")

 

Thanks

[redwoodhead]

That makes sense!

 

But when checking this setting I see that my current setting is already ":fail". But I also see there is an option (under "Advanced settings") to "Discard (Not recommended)" (The current setting is actually "Discard with error to sender (at SMTP time)", which seems to be an option that is interpreted as ":fail".) So, I will give the "not recommended" option a go. (I can't immediately see any advantage in accepting and storing email from anybody who doesn't know what my valid email addresses are!")

 

Thanks

Now I see that ":fail" has changed to ":blackhole". Sounds pretty good to me!

[TCH-Carl]

I would suggest keeping the setting to ":fail:" (without quotes, and with : on both sides) instead of :blackhole:

 

Using :blackhole: email is accepted and received into the server in its entirety. It is then processed through exim and only on delivery is it written to the null device (/dev/null) and silently ignored.

This wastes server bandwidth as the email data, or body, of the email is accepted into the server

This wastes server resources (CPU, memory and disk I/O) as the email is fully processed by exim before being finally written to /dev/null

 

 

Using :fail: the email is never accepted into the server. During the initial SMTP negotiation when the senders SMTP server connects to your SMTP server, the sending SMTP server issues a RCPT command notifying your server which email address the email to follow is intended for. Your server then checks whether the recipient email actually exists on your server (a POP3 account, an alias or a catchall alias) and if it does not, it issues an SMTP DENY which terminates the attempt to deliver the email.

This saves bandwidth as the email data is never received into your server

This saves server resources as the email never has to be processed

[TCH-Dick]

I see the problem, you were using ":fail" instead of ":fail:". Without the ending colon the :fail: option will not work correctly.

[redwoodhead]

I see the problem, you were using ":fail" instead of ":fail:". Without the ending colon the :fail: option will not work correctly.

This is all very interesting. And I certainly know very little about the negotiations that take place between SMTP servers. I am just a user that is presented with four Cpanel options. (None of which involve creating text strings like ":fail" or ":fail:" or ":blackhole".) The options are ...

 

1) Forward to email address (Then I get to select an address)

2) Discard with error to sender (at SMTP time) (Then I get to enter the text of the error message.)

3) Discard (Not recommended) (Then I don't get to add anything at all.)

4) Pipe to a program (And then I get to select the program)

 

These choices are just a set of option buttons, one of which gets selected. Cpanel seems to translate 2) into ":fail:" and 3) into ":blackhole:" (My mistake in saying ":fail" instead of ":fail:".)

 

My previous setting was 2) (with an empty string for the error message.) Cpanel seems to translate this as ":fail:". But this has resulted in /mail/cur and /mail/new accumulating junk mail that was sent to invalid email addresses.

 

I was going to start using 3) (which Cpanel seems to translate to ":blackhole:"), mainly because it seemed it would accomplish what I wanted, namely no accumulation into those two folders.

 

I am happy to do whatever is best for all concerned, but option 2) (aka ":fail:") seems to result in the mail being accepted AND stored.

 

I could be confused though. It's happened before!

 

(If the fog doesn't clear spontaneously by tomorrow I will play with the settings available to me and see what happens storage wise.)

[TCH-Andy]

It should be option 2) Discard with error to sender (at SMTP time) - if you still get new emails to invalid addresses being delivered - please open a ticket at get us to check it for you.

[redwoodhead]

It should be option 2) Discard with error to sender (at SMTP time) - if you still get new emails to invalid addresses being delivered - please open a ticket at get us to check it for you.

Ok. I will watch it and see what happens.

Thanks

[redwoodhead]

Ok. I will watch it and see what happens.

Thanks

I just want to cap this thread off in case someone finds and it wonders what the issue actually was.

 

It turns out unrouted email from a different TCH hosted domain (unrelated to me) was being routed to the unrouted mail folder for my domain. After opening a ticket it took a few emails to convince the first responder that what I was seeing was really happening, but as soon as it was in front of Tom Duncan it was fixed pronto. (Many thanks Tom!)

 

So Dick, Carl and Andy were right. It was just that there was something else going on. Many thanks to the forum folk too!

[TCH-Andy]

Thanks for the update and well done Tom