> Actually it's not all that difficult to send a deffered  message, you

send yourself a message

> and then just copy the raw text into the new

message with the added Remail header and send it to maiser.

You're perfectly right, but I hope you will agree that this could be quite uncomfortable if you have to do it more than a few times in a row :-)

 

> That said, if this is really a critical task then you might want to switch to PMail since it does this automatically.  ;-)

I do use Pmail (since 1994, actually...) but I seem to recall the remail extension only worked in a LAN set up, ie when Pmail is allowed to put messages directly into Mercury's queue. Am I wrong?

Thanks again and regards,

  Corrado

It worked. Thanks a lot Rolf.

hmm - good point. We're using IMAP actually, not POP3, maybe that's the reason?

I'll do a test with POP3 as well.

I doubt if this will make any difference at all since I was reading my 130 character subject sent with Thunderbird  3 through Mercury to GMail and a local account using Webmail,  POP3 and IMAP4. 

I did do a test with sending a line greater that 127 character Subject with PMail (v4.53 beta 2) and it appears that PMail will truncate the subject to 127 characters when building the actual message.  I get this using both the internal mailer and Mercury UDG.  I did not try this with any of the release versions of PMail.

 

Below is a MercuryS session log.  The last time doesn't look right.

19:10:12.671: Connection from 74.71.55.217, Fri Aug 20 19:10:12 2010<lf>
19:10:12.671: << 220 lucky.syr.edu ESMTP server ready.<cr><lf>
19:10:12.718: >> EHLO ZZ<cr><lf>
19:10:12.718: << 250-lucky.syr.edu Hello ZZ; ESMTPs are:<cr><lf>250-TIME<cr><lf>
19:10:12.718: << 250-SIZE 0<cr><lf>
19:10:12.718: << 250 HELP<cr><lf>
19:10:12.968: >> STARTTLS<cr><lf>
19:10:12.968: << 502 STARTTLS not enabled by administrator.<cr><lf>
19:10:12.015: --- Connection closed normally at Fri Aug 20 19:10:12 2010. ---

The offline problem is probably due to a bug in MercuryX. Disable that module unless you actually need to use it. If you use it please install this patch:

/Rolf 

For understanding this correct, with literal addresses meant "username@192.168.0.1".

Not exactly, the literal addressing is username@[192.168.0.1] Here's the section of RFC 532, the standard for handling server to server transactions.

4.1.3.  Address Literals

   Sometimes a host is not known to the domain name system and
   communication (and, in particular, communication to report and repair
   the error) is blocked.  To bypass this barrier, a special literal
   form of the address is allowed as an alternative to a domain name.
   For IPv4 addresses, this form uses four small decimal integers
   separated by dots and enclosed by brackets such as [123.255.37.2],
   which indicates an (IPv4) Internet Address in sequence-of-octets
   form.  For IPv6 and other forms of addressing that might eventually
   be standardized, the form consists of a standardized "tag" that
   identifies the address syntax, a colon, and the address itself, in a
   format specified as part of the relevant standards (i.e., RFC 4291
   [8] for IPv6).

   Specifically:

   IPv4-address-literal  = Snum 3("."  Snum)

   IPv6-address-literal  = "IPv6:" IPv6-addr

   General-address-literal  = Standardized-tag ":" 1*dcontent

   Standardized-tag  = Ldh-str
                     ; Standardized-tag MUST be specified in a
                     ; Standards-Track RFC and registered with IANA

   dcontent       = %d33-90 / ; Printable US-ASCII
                  %d94-126 ; excl. "[", "\", "]"

   Snum           = 1*3DIGIT
                  ; representing a decimal integer
                  ; value in the range 0 through 255

   IPv6-addr      = IPv6-full / IPv6-comp / IPv6v4-full / IPv6v4-comp

   IPv6-hex       = 1*4HEXDIG

   IPv6-full      = IPv6-hex 7(":" IPv6-hex)

   IPv6-comp      = [IPv6-hex *5(":" IPv6-hex)] "::"
                  [IPv6-hex *5(":" IPv6-hex)]
                  ; The "::" represents at least 2 16-bit groups of
                  ; zeros.  No more than 6 groups in addition to the
                  ; "::" may be present.

   IPv6v4-full    = IPv6-hex 5(":" IPv6-hex) ":" IPv4-address-literal

   IPv6v4-comp    = [IPv6-hex *3(":" IPv6-hex)] "::"
                  [IPv6-hex *3(":" IPv6-hex) ":"]
                  IPv4-address-literal
                  ; The "::" represents at least 2 16-bit groups of
                  ; zeros.  No more than 4 groups in addition to the
                  ; "::" and IPv4-address-literal may be present.

If they want not setup the server accepting literal addresses, which tools available to forwarding mails this way?

There are none.  You can remove this domain from your local domain if you are not receiving mail via MercuryS and then Mercury core would resend the mail off the server using MercuryE to the other server.

Having a reverse DNS (PTR) record for the website as well sounds like a good idea anyway. If you want to use only one NIC for mail ports it should be possible to do so using TCP/IP filtering, but it might be some work to get it right.

/Rolf 

Mercury filtering can only move messages into new mail folders, so you could move them to a different user, but not to another folder within a mailbox.

Several users have requested more functionality related to IMAP filtering just like you want, but I don't know when that will appear.

 Thanks for your encouraging reply.

 I am trying to implement this first in a virtual environment  and then will shift to a physical system.

When installing mercury, its asking for pmail, so that mercury can 'impersonate' /send message on user's behalf - this is what I understood.  I think, that part will be of interest.

I will update my findings here.

 Thanks again.

So..... Am I right in thinking that if a connection to the smtp server uses smtpauth then its ip address does not need to appear in the Connection Control list? Or are the 2 comments above mentioning authentication suggesting that having an all encompassing range is ok so long as smtpauth is required for relaying?

Correct, the use of ESMTP AUTH is the normal way that is used to block the spammers from relaying off your server while allowing remote users to relay. 

 

[quote user="TheJJ"]

 My Spamhalter.ini:

[SpamHalter]<br><snip>

<br><b>TrainAlways=1</b><br>IgnoreWhite=0<br>ImageParser=1<br><br>[bayDynamic]<br>bayForcedWrites=1<br><b>bayNoSpamBoost=3</b><br>bayClasifyMaxTokens=20<br>bayUnknownProb=40<br>baySpamProb=80<br>bayMaxCorrCnt=10<br>bayOldDays=100<br>bayExpire=365<br>bayWhiteOldDays=100<br>CustomHeaders=<br><br>[bayStatic]<br>bayMaxLength=8192<br>bayMinTokenLength=3<br>bayMaxTokenLength=25<br><br>

Thanks for help,

 JJ

[/quote]

Spammers have got a bit smarter wrt bayseian filters by including more "good" and "random" words.

I recall the docs implying that the "bayNoSpamBoost=3" setting is to err

on the side of caution in a fresh install and should be modified to

suit after a bit of training. 

The 'bayNoSpamBoost=3' setting means that "good" words have 3 x the 'weight' of "bad" words, so spam with sufficient "good" words is passed as 'nospam'.

This, combined with "train always" means that your database is constantly updated with incorrectly classified spam mails, which adds the included "bad" words to it's "good" list and the effect snowballs.

To combat this I have adjusted my settings as below.

Part of my Spamhalter.ini

TrainAlways=1
ImageParser=1
IgnoreWhite=0

[bayDynamic]
bayNoSpamBoost=1
bayClasifyMaxTokens=30
bayUnknownProb=90
baySpamProb=40
bayMaxCorrCnt=50
bayOldDays=30
bayExpire=180
bayWhiteOldDays=365
CustomHeaders=

[bayStatic]
bayMaxLength=8192
bayMinTokenLength=3
bayMaxTokenLength=25

 

These settings work very well for our mail but may not necessarily work for you, YMMV. :)

Hi,

we run Mercury32 4.72 in NDS Mode on Windows Server 2008 with Novell Client 2 SP1 IR3. After some run time, the IMAP server seems to take very long to process new logins. It takes often 30 seconds, sometimes many minutes for a new imap login. Since most IMAP client regularly create new login connections during normal work, this has a serious impact on users. We use stunnel for ssl offloading and especially to use a correct ssl certificate, but the problem persists whether the stunnel runs on the same machine or on another.

Furhter things we see: Since login requests are not processed, the Mercury screen shows dozens of [Not logged in] connections, they often pile up faster than old ones are processed.

Any ideas? How can I check what takes Mercury so long?

Greetings

Markus Borst

Hi -

Sorry to re-open an old thread, but I'm having a similar issue with auto-replies, and changing ISP's isn't an option...

I've been using the same ISP for 14 yrs, and it does relay as long as "any" validly formatted e-mail address is in the MAIL FROM field when sending an outgoing message - just apparently not when the MAIL FROM field is empty (<>) as I've found out recently when attempting to use auto-reply.

Hoping to get more insight into why the MAIL FROM <> response doesn't contain a valid user.

Based on  the help file info - MercuryC / Forced SMTP sender  - it sounds like we should be able to always have a valid MAIL FROM user sent to the outgoing server for validation.

I've tried changing various settings, including adding various headers via outgoing rules for the AutoReply message that don't appear to be included by default in auto-replies ( Return-Path:, From:, Resent-from:, X-AutoForwarded: ) as well as adding the forced smtp sender, etc.

I guess my expected behavior, for auto-replies, would be for MercuryC to use either the "receiving" mail account name as the "MAIL FROM<>" account when sending the auto-reply, or use the postmaster / forced smtp sender account in the MAIL FROM<> field.

Is there something I am missing / some way to cause MercuryC to always populate the MAIL FROM, and / or any way to add the MAIL FROM user via outgoing rules (it's not a header, but is typically taken from the Return-Path or From field I believe).

Oh - and i can include a full connection log from my server to my ISP for an auto-reply if needed, but the relevant issue field is the same as Dave shows above - the empty MAIL FROM:<> response

22:25:28.265: << MAIL FROM:<> SIZE=676<cr><lf>

Thanks for any help anyone can give.

Chad

That works great, just what i was after. :)

Thanks again,

Troy

well thans for tryingto help me after 5 more hours of fiddlinh with it i used port 3476 on mercC and had it relay to my domain and it works now fully i can recieve and send mail to local and external thanks for the help and input though

Hey, Rolf, thanks a lot for answering.

I did not realise that the MX record order could be ignored.

We had locked down Mercury so that SMTP connections were only accepted from MessageLabs' IP addresses. However, because our staff use IMAP and they have dynamic addresses assigned by their ISP's for their home machines I opened it up again so they could authenticate and send mail. I'm going to lock it down again and update their IP addresses in Mercury as required.

This is the first email that has been delivered directly to our IP address. I guess we've been lucky that no more arrived.

Thanks again for the help.

Thank you, Rolf.  I had already tried putting in two forwarding rules and one of them didn't work.  However, after seeing your note, I tried again and the mail was forwarded to both locations.  Maybe I incorrectly typed something the first time.

Thank you

Gordon

Thanks for the reply.  I'll give these a try.

If it was me, I would delete the newly installed versions, drop the old versions into place, verify that they work as before, then run the upgrade over them to get the new versions.

Found out sumthin. There was a user that was draging and dropping received emails from there inbox to the spam Archive, and Drafts folder.Once i removed the emails from the spam account folders, the error went away.

Thanks,

Troy