thnx for helping me, it was a firewall, thnx again

No, you can't assign rights to a mailbox to a group of users. You could create a separate mailbox and give all users in the group the password, of course, but then you would need to change the password if someone is removed from the group to be sure to prevent access. Another solution would be to copy all messages for the group to the individual mailboxes of the group members. This can be done using a list or by creating an alias connected to a rule.

/Rolf

This is another way of solving the same thing:

Hello David,

I currently have the mercury.exe setup as a service.  I'll change it to use the loader and keep an eye on it.

Thanks,

Ed

Thank you - at least I can stop looking.

Definitely upgrade to the latest, 4.62

Hi

 this happen two/three times per day and always same address 0X0001008b

Assuming that gmx.de is the domain that this server is supposed to handle mail for you need to check the Local domains section in Mercury core configuration. Have a look at the help text to see how to do it.

If gmx.de is not your domain you are acting as an open relay, which is very bad. In that case go to MercuryS configuration, Connection control to correct it. Having the first two checkboxes checked (strict restrictions) is a good start; more information about the options are in Mercury help or the manual.

As for the error message, "555 5.5.2 Syntax error. j2sm5603868mue.4" doesn't look like a message from Mercury. Switch on session logging for the module in question to see what actually happens. (Remember to switch it off again, though.)

/Rolf 

Hmm.  Access to the list at UA may be needed to follow this up - try the listowner with specific message times.  I know they stepped up their anti-spam protection a while back, but maybe this is a problem.

[quote user="PaulW"]

[quote user="Jean-François Berne"]Is it possible to allow weak identification for some IPs ? I can't find this in the 'Connection Control' tab of MercuryS config.[/quote]

If it is a fixed IP address on your LAN, you can put it in Connection Control and allow it to relay (if that's what you want).  No authentication applies then - assuming you don't have the bottom box ticked (Only authenticated connections may relay), and you could turn it off in the camera.

How do your other workstations on the lan send mail - by authentication or IP address allowed?

[/quote]

Answers:

• I HAD checked the box 'only authenticated SMTP connections may relay', which means that ...
  
• ... others workstations on LAN (and on WAN) sent authentification;
• camera had/has fixed IP

So I read again the help with your remarks in mind and actually solved the pb:

• uncheked  'only authenticated may relay', but with...
  
• ...strict local relaying
• just the camera's IP in allowed connections list
• kept weak auth. disabled
  

Now, all mail clients still must authenticate themselves with strong auth. - as they always did. Only the cam may relay without auth. at all, which is precisely what I needed.

Thank YOU !

JF 

Thanks
Anyway to sort this ?

I need to ensure the subject is changed before the email is sent out..

You should be able to solve that part by using Attributes / Originates from a non-local source / Move message to another user (instead of Always triggers).

/Rolf 

Thanks I try this over the next day or two and see how it goes.

[quote user="Peter Strömblad"]I've checked dessergroup2.demon.co.uk and it's not a valid domain[/quote]

It's a sub-domain.

[quote]The domain demon.co.uk also yields a number of warnings[/quote]

They look like minor issues even with your tools.  Certainly nothing that Mercury should stumble over.

Ah, that's true - at present Mercury only supports TLS when using MercuryC (SMTP relay module) for delivery, not MercuryE. Sorry for mixing it up.

/Rolf 

Great! 

Here is some information about the forum: h 

Please post additional questions about that to Feedback on this website.

/Rolf 

Thanks.

Anyone know of a quick daemon that will do this ?

I sort of agree with that, but I feel I should point out that it's not SpamHalter that's writing the console message, it's Mercury core. And Mercury core is only aware that a job in the queue was deleted by a daemon, it doesn't know the reason. 

/Rolf 

Certainly.

I'm submitting 5000 messages in rapid succession using a Java application which uses the javax.mail API.

The messages are small.... less than 1kb.

 I can send and receive low volumes no problem.

Not sure what the temp directory is.... where do I find this in the config? I'm running with the install defaults btw and running the latest  version 4.62.

 Anti-virus.... good thought! Yes, I do have real-time scanning going on. I've excluded the mercury directory and will test again tomorrow.

 Thanks

Under the Pop3 server config, make sure "Offer only unread mail to connected clients" is unticked.

This is really the only Mercury setting that effects this process, it is up to the client which messages to request.

"Mark retrieved mail as read" may or may not have an effect, you will have to experiment.