Community Discussions and Support

The perfect forum for general discussions or technical questions about Mercury Mail Server.

0
-1
closed
Methuselah posted Oct 8 '07 at 10:16 am

[quote user="Rolf Lindby"]

If you block all incoming messages with <> as sender you may block more than you intend to. Delivery failure messages from SMTP servers can have that as well.

/Rolf 

[/quote]

Thanx for that heads-up.
At present I am moving the messages to a black-hole mailbox that I monitor.
I'll keep an eye open for that sort of message before I institute "killfile" :)

0
-1
closed
airyt posted Jul 10 '08 at 5:33 pm

Yup -- not ignoring the actual issue, i was just looking for a workaround as there has been no indication that this issue is in the queue for updating.

 

My thoughts/wishlist for the autoreply issue would be as follows:

1/ The length of time to suppress subsequent auto-replies be configurable.

2/ Then, for every account, simply keep a file where email addresses and a timestamp are kept on each line.

3/ Then, when a message comes into the account (and the account has autoreply set to on), the sending email address is checked in the file. If found, check the timestamp against the current time and send (or suppress) an auto-reply accordingly. Then update the timestamp in the file if an autoreply is sent. If the email address is not found in the file, append the email address and current timestamp to the file and send the autoreply message.

 

Seems fairly straightforward to me. :)

 

best, gw
0
-1
closed
PaulW posted Jul 17 '07 at 5:25 pm

DNS MX records should contain a host name - that is a name you have set up with an 'A' record pointing to an IP address.

 

0
-1
closed
PaulW posted Jul 13 '07 at 6:30 pm

[quote user="madbuffalo"]Yes they are correct.  I have used up to three actions on the same line before. i.e. (BSL)[/quote]

I've just done some tests, and I'm not seeing that.  You get a log entry anyway if Mercury blocks and send a response - you don't get an extra one with an 'L' in the final position.  I get exactly the same entries with 'R', 'RL', 'R-L' or 'RSL'

[quote]As for the 'N', I have never used it--so I am not sure if the functionality is there or not.[/quote]

It is still working - it must be an omission in the help.

0
-1
closed
NetwareRulez posted Jul 10 '07 at 6:53 pm

Hi,

I'm using Pegasus on Netware (NDS mode) with Public Folders. Configured Merc/32 4.51 to deliver directly to the Public Folder via an alias.  Works like a charm.

Is there any way to notify users of new mail arriving in the Public Folders (the same way as new mail arriving in their personal folders) without running 3rd party tools?

Thanks

Ron

0
-1
closed
dilberts_left_nut posted Jul 16 '07 at 4:06 am

If it's not in your CC filters could it be coming FROM another mercury server's CC.

Check Received headers for another merc system?

Don't know if these are supposed to go on outgoing mail though. 

0
-1
closed
nils posted Aug 22 '07 at 3:27 pm

Is this the way to do it for all of us with support subscription, I mailed the support account before summer regarding this but not reveived an answer yet. It is a bit annoying running with crippled interface.

 

Best regards and thanks for the superb software

/Nils 

0
-1
closed
Rolf Lindby posted Jul 9 '07 at 9:27 pm

This is what the help text says:

Local user  If you enter the name of a local user on your system (one to which Mercury can deliver directly) then all the mail downloaded from the remote account will be sent to that local user, irrespective of the address fields in the message. If you leave this field blank, MercuryD will examine the To, CC and BCC fields of each message looking for addresses it recognizes as local. When it finds a local address, it will send a copy of the message to that local user.

As far as I can tell no address headers in the message should be checked if a local user has been defined. 

 /Rolf
 

0
-1
closed
tomt posted Jul 10 '07 at 12:08 am

I emailed the author of the clamav version I'm running.
He suggested trying the SVN version.

I've tried that and now it launches in a couple of seconds with NO event log errors.

Thanks :)

0
-1
closed
Rolf Lindby posted Jul 11 '07 at 4:42 am

Unless there is support in M/32 or the new daemon interface for recalculating the queue counters a webadmin interface won't help much in this case, though. If there is support for it I'd be happy to add the function to my web interface.

 

/Rolf 

0
-1
closed
PiS posted Jul 10 '07 at 11:47 pm

Interesting, I'll play with this in a test environment later on and let you know what I find - I say interesting because it is something I can elaborate on in the webadmin for a domain since many have asked about how to divide and distribute info between departments.

0
-1
closed
tomt posted Jul 10 '07 at 12:09 am

Thanks.

Installed and seems to be working very well.

0
-1
closed
trickydude19 posted Jul 8 '07 at 7:48 pm

Okay, well thanks a lot for the help, I'm pretty sure I got it working properly now!  What happened was, I logged into my DNS center and after searching around for a while, I finally found out that, by default, the mail was being redirected to my hotmail account.  I just wish that it wasn't set as default like that without me even knowing, and it would have saved a lot of stress.

Oh and I can send and receieve e-mails properly now, so thanks a lot guys, I really really appreciate it!!   

0
-1

Most any unused port is valid for receiving mail from your e-mail clients, port 587 is normally used for mail user agents.  Mail sent from other servers to MercuryS though must be received on port 25.  You can configure MercuryS to use port 587 as well as port 25 and you can also use TLS secure links and authorization.  Mail servers sending through MercuryS may or may not be able to use the secure connection so you must not disable the unsecured connections.

 

0
-1

For a variety of reasons, Mercury is quite strict about enforcing the syntax of the MAIL FROM: and RCTP TO: SMTP commands. The main reason is that syntax errors in these commands are a common indicator of spam (no properly-written SMTP client should ever be getting the protocol this badly wrong). The secondary reason is that a number of open relay testers use deviant or invalid forms like this as part of their test, and evaluate the server based on how it handles them.

As Thomas has pointed out, the syntax for these commands in RFC2821 is quite specific - you can't just throw any address format in there. If your mail clients are getting this so badly wrong, you need to get back to their authors and suggest that they re-read RFC2821, then correct their code.

Cheers!

-- David --

2.31k
13.66k
8
Actions
Hide topic messages
Enable infinite scrolling
Previous
Next
All posts under this topic will be deleted ?
Pending draft ... Click to resume editing
Discard draft