[quote user="tokul"]

If you think that issue is solved in some beta version, could you give me link to that beta? 

[/quote]

I've now looked back on the code I used to build v4.01c, and it's possible that I used the wrong base code set. It may be that the code I used to build v4.01c had an early prototype of the modified UTF-7 code, where it shouldn't have had anything at all. Unfortunately, the v4.01c build was done in a bit of a hurry (because it was addressing a reasonably serious security vulnerability), so I can't be totally sure about this.

Certainly the modifed UTF-7 code appears to be working fine in v4.5, at least based on reports from the test team.

As Peter has said, betas are currently not made available publicly, although I'm considering changing that: I may well go down a path where selected relatively stable betas will be made available to the public on the basis that they are undocumented and unsupported. Unfortunately, v4.5 is now so late along in the process that it's actually not easy for me to make a beta available to you, or I would consider doing so. Leave it with me and if I get to a point where I think there's something I can offer you, I'll get in touch.

Cheers!

-- David --

I sent a mail to fred from Mercury. ok.

 

Recieved the mail in TBird ok.

 

Somehow I don't think TBird is sending correctly or I have screwed somthing up I can't see, 

> Did you use a relaying mail server or did you set up a completely new
> for the domain? - I set up a full webserver and mail server (all on
> the same box). And had the problem right away.

Completely new domain and Mercury/32 server.  I go the domain from DynDNS.com and it used a fixed IP address so I was sending via MercuryE.  There was no problem at all that I could see sending to the Yahoo addresses I have in my addressbooks.  Of course, I have never had any problems sending to Yahoo.

> As for DKIM still being able to spam, and hence domains using DKIM are
> marked as spam, should not really come as a surprise.

Agreed,  I've read someplace that the spammers are some of the most compliant is the SMTP host out there.  

> I'm merely refering to Yahoo policies as stated on their mail help. -
> The place to find this spam identification is located in the header
> information of the mails send. Even if a mail arrives in the normal
> inbox, a previous whitelisting by the user will cause the mail to
> arrive there and not end up in spam.

Yahoo does require that the domain have a valid PTR record but other than that I've not had any problems at all sending direct to Yahoo addresses.  

How do you recommend that this be done when the mail is to a valid address?  I guess you could remove the capability of maiser ever sending any respones to non-list members or moderated lists but that to me does more harm than good.

If the list is small and relatively fixed you can copy the list addresses to a dist. list and then do a list scan filter and delete any mail from a non-subscriber. 

Personally, as recommended by David, I use POPFileD to catch the spam.  This catches 99.87% of the spam and moves it to a spam user account so it very seldom gets to any of the mailing lists.  ;-)

 

Just tried two messages I've seen this week.

1) Loooong header line (MS Outlook x-cr-hashedpuzzle:)

2) Long lines in an inline text attachment sent by Thunderbird 2.0.13. Format "flowed".

Both worked fine when downloaded from 4.72, not from 4.01b.

Guess I'll have to upgrade. 

If you track a bounce and figure out who it was originally to, then do a search on that address via google or similar, and you'llmost likely find the info sitting in some web-page (mis-spelled, archived or active) - then you know for sure it wasn't a lapse of open relay.

4.01b

 I managed to get it working, but it's a real kludge.

• I deleted myself, user "Pete" from Mercury
  
• I created a new user called mailbox which I now send with a reply-to of "pete@"
• I created a mailing list "Pete"
• I created a mailing list "Tmob" for my T-Mobile device with no welcome nor farewell file and made the mobile device address a moderator and active subscriber
  
• I created a mailing list "Cing" for my Cingular device with no welcome nor farewell file and made the mobile device address a moderator and active subscriber
• I subscribed mailbox, tmob, and cing to Pete

I can now do what I wanted. EMailing maiser@mydomain

add tmob any@email blah
mset any@email tmob nomail

will forward that address to the device, and

remove tmob any@email

will stop forwarding. (I replace "tmob" with "cing" to do the same from my cingular device). But like I said, it's kludgy.

We use port 110 on the local network and a random high port externally.

The internet gateway 'port forwards' this high external port to port 110 on the mail server so merc only needs to use one listening port. 

Should make no difference where the mail comes from in MercuryS. Or do you mean POP3 download using MercuryD? Anyway, temporarily switch on session logging for the module in question to see all details of the transaction. (And remember to switch it off, it wastes a lot of disk space otherwise.)

/Rolf 

[quote user="Slab"]

I just had a problem with the outbound mail queue freezing.  What happened is a spam message came in with an invalid email address going to an invalid email address ( to invalid2@mydomain.com)  What happens is that a return notice keeps bouncing in the queue trying to send the non delivery receipt to an email address that doesn't exist internally.  Is there anyway to prevent this from happening.  I've had messages get stuck in the queue before, but this is the first time it actually hung processing.

Almost forgot.  It is running on a Win2k server.

[/quote]

 

What I do is turn all mail being received for invalid local users in MercuryS.  If mail is received via MercuryD leave the local user blank so that Mercury core delivers the mail and mail for all invalid users goes to the default user without a bounce.  With this setup MercuryS rejects the message before it's received so no bounce message is generated.  With mail received via MercuryD the default user processes it as desired.

 

 

The problem is less something specific to Mercury than a widespread problem in the way SSL is implemented generally. There are many different libraries and versions of libraries for doing SSL and not all of them interpret the specifications in the same way.

Now, with MercuryP, MercuryI, MercuryC and MercuryD, it's not too much of an issue, because they're only talking to a fairly limited range of implementations, so if there's a problem, it will become obvious at an early stage. Enabling SSL in MercuryS, though, exposes you to every implementation in Christendom, with all their vagaries and differences. For this reason, I generally do not recommend enabling SSL in the SMTP server - and will not be recommending it until the industry settles down considerably in this area.

Cheers!

-- David --

It's all sorted [:D]

Turns out that it was just the password stuff in Mercury that had become corrupted - new password setting - job done.

Can't believe I have spent 5 days driving myself (and everyone else) mad over this.

Thanks again and hopefully back to another happy and trouble free five years of Mercury & Pegasus.
Oh! and once you sort out the licensing stuff - 5 mailboxes here please

Lynn
 

@

 

You posts and your sites deliver a quite considerable hype on something that's been around 3+ years now.

 

Question: what makes your "Hermes" better than the other 150+ plain-whitepaper Greylisting implementations available everywhere? 

THAT would be a really useful information to all of us...

 

Thank you!

 

After setting up ClamWall I just fount three files left, and they look to be left while the server was starting, and therefore ClamWall still was loading. It looks like to be some kind of time-out, then.

ClamWall can quarantine infected messages to a file system folder, what it can do is to quarantine them to a mailbox, and to check a file folder remotely is more cumbersome than checking a mailbox - and requires to have the right TCP ports open on both ends.

Thank you for your help.

 

[quote user="OldManRiver"]

1. Move the Email to the appropriate mailbox (the rules tool does not always do this),

[/quote]

In that case you need to rework the rule. While there is a to-do list for Mercury, there aren't any known problems with the rule engine - it's been around for well over a decade now and is quite proven. If a rule isn't working the way you expect, then you need to reconsider the expression or terms you're using to trigger it.

As for the rest... You can proceed in one of two ways:

1. You could create a rule that executes external program that does the processing you need.
2. You could create a Mercury policy that passes the message off to an external program.

Extracting the attachment to the directory is probably possible using a rule (depends on whether or not the excel attachment explicitly includes a recognizable file extension, but it almost certainly will). Printing is a little more complicated - you *might* be able to do this from a "Run a prorgam" rule, but that depends on your system and the applications you have available. The policy or external program approach would give you the greatest flexibility in how you proceed.

Cheers!

-- David --

[quote user="Paul"]

This post in brief: To have the MercuryP POP3 Server give you your emails in the order they were received (FIFO) you must use FAT32. If you use NTFS they will be mixed up.

[/quote]

I just want to make it clear that you mustn't rely on the order of messages provided by a POP3 server  - ANY POP3 server, not just Mercury. The RFCs for the protocol make no mention of ordering, which means that there is no standard interpretation. If Mercury presents messages in a particular order because of a foible of the underlying file system, then that is an accident, not a matter of design.

Now, with the preceding paragraph in mind, it *would* be possible to add a degree of sorting to MercuryP - quite easy, in fact... But it would always have to be a specifically settable option. I'll take a look at the code and see just what might be practical.

Cheers!

-- David --

 

Ben, most likely you're suffering a reverse lookup problem. To my knowledge, both Google and Microsoft require valid reverse lookups as to accept inbound e-mails. As stated above, youre HELO or EHLO needs to match your actual sending IP that in turn resolves when doing a reverse lookup. Check up on your own host and mailer, to see how it complies by using the DNS-Report at: .

Also, you say you don't worry too much about inbound, - you should! If your mailserver is reported as an open relay, you will be treated as a spammer. Now, since you most likely only will allow SMTP connections from the very same machine, insert Allow 127.0.0.1 into connection control options of MercuryS module. Since we serve many domains, we nearly only allow authenticated SMTP connections to relay, meaning to check the last two boxes on Connection Control in MercuryS. Besides the authenticated, some internal servers are allowed within connection Control, all else is thus only allowed to connect with inbound email to local addresses.

[quote user="bfluet"]Paul is dead on.  My ISP is Deltacom and it's their server address that is being written to the From header.[/quote]

What this indicates is that the message is going out without an FQDN (fully-qualified domain name) in the From: field. So, say the user's name is "Bill", the from: field is going out as "From: Bill" instead of "From: Bill@domain.com". The ISP will be running Sendmail, which normalizes messages that aren't conformant in this way (although what it does is not actually very useful).

For the life of me, I can't remember if this issue was ever resolved during the v4.5 development process or not - I certainly remember looking into it, but I can't remember what the outcome was. If I can get a chance this afternoon, I'll take another look at it, but if you find it still happens after v4.5 gets released, raise the issue here again and I'll look into it in more depth.

Cheers!

-- David --

[quote user="SteveYates"] When delivering mail to a mailing list, Mercury resolves the MXs first and then tries to deliver messages destined for the same MX together in one SMTP session instead of separately.

 <snip>

T 20070509 092400 4641d236 Established ESMTP connection to 64.18.7.10
T 20070509 092400 4641d236 MAIL FROM:<Mary@example.org>
T 20070509 092400 4641d236 250 Ok
T 20070509 092400 4641d236 RCPT TO:<user@example.com>
T 20070509 092401 4641d236 250 Ok
T 20070509 092401 4641d236 RCPT TO:<user2@example.net>
W 20070509 092401 4641d236 451 Recipients not all at same mail host - psmtp[/quote]

Why doesn't postini allow this? And as a consequence why have the mailadmin set the same mx for both domains, if postini doesn't allow this behaviour?

Have you asked the postmaster at 64.18.7.10 about this issue?

I don't think you need to install a email server for this, assuming your isp has a smtp-server  you can set smtp = <isp-smtp-server> in php.ini.

http://uk.php.net/mail