> 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.  

Hi,

Is it possible for Mercury/32 to be configured to use DKIM?

How will it work in a multi-domain name enviroment (one server, one IP, multiple domains)?

Personal input:
It looks like DKIM is getting some traction and it may soon be used to spam filter or whitelist emails.  Either case is bad if your mail server doesn't support it.

[quote user="Moshe"]How will it work in a multi-domain name enviroment (one server, one IP, multiple domains)?[/quote]

My understanding is that DKIM creates the signature based on the domain, and is designed to cope in a multi-domain configuration - the IP doesn't really affect this.

[quote]Personal input:
It looks like DKIM is getting some traction and it may soon be used to spam filter or whitelist emails.  Either case is bad if your mail server doesn't support it.[/quote]

That remains to be seen.  Both DKIM and the earlier SPF are now RFCs (4871 & 4408), but many people remain unconvinced that either will have much effect on unwanted mail. 

[edited to include rfc references and links!] 

Mercury runs fine with multiple domains. We're currently serving over 100s on 3 installs of Mercury.

Don't know what DKIM is.

All installs have local mailboxes, with names composed like m####$$$, where #### is customer number, and $$$ is sequential number.
Alias lists created from external administration database attaching alias to real address, ie: full.email.name@domain.name == m####$$$
with added off host relays as well.
Mercury.Ini contains what domains are served by each particular install.
Each install configured to use its own ip, through multiple ip config in Networking Options.

[quote user="Moshe"]
Is it possible for Mercury/32 to be configured to use DKIM?
[/quote]

Not at this point, no. DK is considerably more technical and complicated than SPF, although on the plus side, it doesn't suffer from some of the really glaring flaws that SPF has - in particular, DK doesn't complicate autoforwarding or list mail to anything like the same extent as SPF.

I've been watching both these technologies for quite some time - I actually know Dave Crocker (the man largely behind DomainKeys) from APCAUCE connections. I have never cared for SPF, but I quite like DK (note that I am not trying to start a religious war here, so please don't be tempted to rise to the bait). That said, I probably won't be investing any significant effort into either until it's clear that there is a groundswell of adoption among major players, and at the moment there's only very minimal adoption across the entire Internet for either of them.

[quote user="Moshe"]

It looks like DKIM is getting some traction and it may soon be used to spam filter or whitelist emails.  Either case is bad if your mail server doesn't support it.
[/quote]

I guess it depends on whose press releases you believe. My own view is that adoption on both SPF and DomainKeys is so slow and so minimal at this point that any attempt to do actual filtering on them (as opposed simply to using them as hints in a larger equation) would be suicidal. I estimate at least three to five years before any widespread adoption is likely to occur, based on the progress I've seen in the last five years.

Cheers!

-- David --

PS: Using the new event-driven interface in MercuryS v4.5, it's probably possible for a Daemon developer to write DK or SPF support into the program externally, but that's another discussion.

I'm not sure I agree with the adoption rates.

 There have revecently been a major push with articles about DKIM popping up everywhere (slashdot/etc...) which include major names that are starting to use DKIM (already implemented).

Check your mail headers, look for the DKIM headers on your incoming mail and then do a quick calculation.  Do this 6 months from now as well and then let us know what percentage of your mail has these headers.  ;-)

Thomas:

Taking that approach (waiting to see what everyone else does) is an aweful way think of things.  Trying to implement upcoming standards is the way to move forward and convice others to do the same.

Not really, there are a LOT of failed "standards" out there.  If a developer jumps though hoops to support every new RFC that comes down the pike they are going to be spending a LOT of valuable time developing code that will never be used.  A standard that does not get around 70%-80% support worldwide it going to do little or nothing; currently DKIM appears to have less than 1% support worldwide.  

[quote user="Moshe"]

Taking that approach (waiting to see what everyone else does) is an aweful way think of things.  Trying to implement upcoming standards is the way to move forward and convice others to do the same.

[/quote]

That depends on whether or not you think the feature is compelling or not. Looking back many years ago, I implemented MIME support long before it became a formal standard, because I believed it was a compelling technology that the world needed badly. The same has been true of other features - I have based my decision whether or not to implement them on my knowledge of the marketplace and the needs of my users. So far, I've been right far more often than I've been wrong... I realize that that might sound a litte arrogant, but it's not meant to - it's simply that for every one standard that makes it into the main stream there are four or five others that don't, so a reasonably cautious approach tends to work well. Seventeen years of doing this may not count for much, but it *does* mean that I have plenty of experience to fall back on in this type of thing.

Once it becomes clear that: a) DKIM or SPF will solve the problems they claim to solve (still not proven), and b) that there is a solid groundswell of opinion falling into line behind one or the other (or both), then I'll definitely be in there, but this isn't MIME and I don't see it changing the world the way MIME did, so a certain level of circumspection seems entirely appropriate.

Cheers!

-- David --

Today it was reported that "Yahoo! Mail will be releasing a new security upgrade

to their email system that is said to block spam, particularly all that

junk you might be getting for eBay and PayPal scams. They call the new

technology 'DomainKeys', and it will block all phishing, spam and

fraudulent emails that might try and sneak in to your inbox."

So no one uses a Mercury Server will be able to send e-mail to yahoo.com email addresses right?

[quote user="cj88"]

Today it was reported that "Yahoo! Mail will be releasing a new security upgrade

to their email system that is said to block spam, particularly all that

junk you might be getting for eBay and PayPal scams. They call the new

technology 'DomainKeys', and it will block all phishing, spam and

fraudulent emails that might try and sneak in to your inbox."

So no one uses a Mercury Server will be able to send e-mail to yahoo.com email addresses right?

[/quote]

If Yahoo really does that, I can tell you that I will completely block them as well. With all the Nigerian- and China-Spam THEY send out, if they don't want my user's legitimate emails, I don't want theirs either anymore. And I'd suggest anyone to do the same. Microsoft has had similar plans to enforce their crap. But as the internet community announced exactly this reaction, they quickly revised their plans.

[quote user="cj88"] So no one uses a Mercury Server will be able to send e-mail to yahoo.com email addresses right?[/quote]

Where did you read that yahoo would refuse non-domainkeys signed email?

Turns out that the Yahoo Domain keys is only going to be applied to email from paypal and ebay

Ive contacted yahoo a few times to get our mail server unblocked. They keep mentioning about adding domain keys. I think if you added domain key support on your server it may help yahoo stop 'Temperarily deffering' the server, i wouldnt have thought they would block any emails that were not using DK because of older software that didnt support DK?

[quote user="Craig"]Ive contacted yahoo a few times to get our mail server unblocked. They keep mentioning about adding domain keys. I think if you added domain key support on your server it may help yahoo stop 'Temperarily deffering' the server, i wouldnt have thought they would block any emails that were not using DK because of older software that didnt support DK?
[/quote]

I've never used domain keys and I always get through to Yahoo.  Yahoo does block on a randomly assigned IP address and might be blocking where the rDNS text shows what is apparently a rendomly assigned IP address.

[quote user="Thomas R. Stephenson"]

[quote user="Craig"]Ive contacted yahoo a few times to get our mail server unblocked. They keep mentioning about adding domain keys. I think if you added domain key support on your server it may help yahoo stop 'Temperarily deffering' the server, i wouldnt have thought they would block any emails that were not using DK because of older software that didnt support DK?
[/quote]

I've never used domain keys and I always get through to Yahoo.  Yahoo does block on a randomly assigned IP address and might be blocking where the rDNS text shows what is apparently a rendomly assigned IP address.

[/quote]

Yea they say the rDNS has to have your domain name init but we recently changed our IP Address and they didnt rechange the rDNS but we could still send emails to yahoo. But every now and again they'l get blocked.

i was just looking to add domain keys, just to tick it off the list of 'why you could keep getting blocked' type of thing If you get me? 

To wake up an old topic, DomainKey implementation to Mercury mail ...

 The latest RFC is from july 2009, and is numbered RFC-5585

 http://tools.ietf.org/html/rfc5585

I'm not saying this is the all encompassing solution, and I do understand the problems in choosing just one of such attempts at spam prevention mechanisms as _the solution_

It's unlikely the only way to go, and it may be only "few" mail providers that support this. However, Yahoo! has their feet on this thing, and if you're not DKIM or on their "whitelist", you're dumped into the spam folder. This is afaik the "only" mail provider that I've seen, that dumps mail into the spam folder if DKIM or "whitelisting" hasn't occurred.

My point is: If you set up a new domain, and want to use mercury/32 as the mail server, then you're out of luck when sending to ANY yahoo users, since the domain is going spam right away. - According to Yahoo documentation, using DKIM should prevent this from happening.

I have two domains on the same IP range, and my "old" domain has no problems sending mail to Yahoo users, it hasn't problems sending/relaying mail for the "new" domain either. But as soon as I attempt to send mail from the "new" domain server without relaying through my "whitelisted" "old" server, then I end up in the spam folder.

So - allthough this annoying method of "securing" mail, isn't required, it does lead to annyance when not available off the shelf. - I'd be happy to go for a user contributed solution for the problem, i.e. unload the main developer from the responsibility to create and maintain such an addition, however, is it even possible to get to that point?

I've been happily using and recommending mercury mail since 96, however this little annoyance may eventually lead me to drop the server. So please, if there's a way to get this implemented, either off the shelf, or through user contribution, maybe it's time to reconsider.

> My point is: If you set up a new domain, and want to use mercury/32 as
> the mail server, then you're out of luck when sending to ANY yahoo
> users, since the domain is going spam right away. - According to Yahoo
> documentation, using DKIM should prevent this from happening.

Strange, I ot know why this would happen.  I just setup a new domain and then sent to yahoo mail accounts without any problem at all.

I addition, I just went thru today's spam and found 20 of 110 spam messages that contained a valid DKIM header.  I assume that these were sent via botnets using the zombies own valid SMTP host.

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.

As for DKIM still being able to spam, and hence domains using DKIM are marked as spam, should not really come as a surprise. 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.

I'm going to investigate this a little further before I can make any conclusive proof of what is really going on though.