I think I have found the option. Checking "Suppress validation of "From" field when processing mail" in Mercury Core/General seems to allow any (invalid) "From:" address.
Gordon
I have been running an application called from Mercury Global Filtering which examines incoming mail and, through a set of rules, decides whether to send a notification to my mobile phone. The notification comes to the phone in the form of a test message, after sending an e-mail to the phone's e-mail address, which invites me to read the message. The notification provides the e-mail address of the sender of the original e-mail. So that I can decide whether or not to check the e-mail (and incur the cost involved), my application provides a tailored notification which generates a From address containing some basic information about the sender and the subject. An example might be an address of the form JohnSmith_at_email.com@invite_dinner.com. The domain name is, of course totally artificial, but gives me a clue as to whether I want to immediately read the mail or wait until I get home. The ISP SMTP server that I have been using has been accepting e-mails of this nature without using AUTHoriization and without any checking of the validity of the domain. This has now stopped, presumably as a result of tightened security.
I have been wondering whether I could replace this lost service by using my own Mercury SMTP server. However, to do this, I may have to allow the server to provide open relaying, which I obviously don't want to do. I have also investigated whether I could generate new Mercury users on-the-fly with my application, by automatically editing the user details in Mercury\Mail, e.g. a user called JohnSmith_at_email.com, which I could remove after the notification has been sent. However, so far as I can see, Mercury has to be re-started after making changes in the Mercury\Mail directory for such changes to come into effect, which is not a practical or an attractive thing to do automatically.
Maybe, I could allow open relaying but block access from outside with my firewall. I am not sure that this would help or how practical it might be.
Can anyone offer any advice about this (perhaps a bit strange) requirement.
Thank you
Gordon
In the MercS config - Connection Control, you can add the IP address of your applications machine and tick the box "Connections from this range may relay", while still denying relaying without AUTH for everyone else.
Well, unfortunately, this didn't work. The message failed because "User XXXXX not known at this site". Maybe this is because the mail is being sent from the machine running Mercury and not another one trying to relay through it. I had checked the "allow relaying" box for 127.0.0.1
Gordon
That looks like a "RCPT TO" failure. Is the To: address a local user on your Merc server?
Maybe a bit more detail for the actual addresses & some headers would help explain what you are really trying to do.
You have to tell us what module you're using, MercuryE or MercuryC - there are more flags involved when stopping/allowing relaying than just the connection control at the IP-level.
DLN - I have tried sending to both local and remote users and the result is the same failure.
I think that the bottom line here is whether MercuryS can send mail from a local user who does not exist.
Gordon
Peter - I stand to be corrected, but I don't believe that the SMTP client is the point at issue here. It seems to be the SMTP server that is rejecting the (non-existent) local user, when using msendto.
However, if I telnet (25) to MercuryS, the MAIL FROM:<unknown_local_user> input results in a Sender OK response, but I don't know whether this proves anything.
Gordon
P.S. (Edited) I have just tried to send mail manually and, though Mercury S doesn't show any signs of complaining, the From: name is still being rejected as unknown. Maybe the SMTP client is doing this.
