Pegasus Mail & Mercury

I have MercuryS debugging turned on and have noticed the following connection information:

Connection from 114.111.32.72, Tue Oct 6 07:12:11 2009

EHLO rcvmail2.nm2.naver.com

MAIL FROM: <>

RCPT TO:<real-address@tallulahfalls.org>

DATA

DATA - 15 lines, 401 bytes

QUIT

We do get valid mail from this domain (naver.com) so I cannot block them outright. Any suggestions as to what can be done to stop the delivery from the <> address?

Thanks for all your quick responses!

Mail from <> are postmaster mails, and is used to prevent mail loops.  Legit <> messages can vary from callout verification to non-delivery reports.  Of course spammers have also used them.

You haven't said what is in these mails or why you want to block them, but you may be able to choose another characteristic, if necessary.

I too have been receiving these from various IP's from spammers.  Unfortunately, there are no other characteristics on which to filter the messages.

 Is there a way to filter an empty FROM field?

 I've configured a Global Filter rule:  If header "F" is "" Delete "" - but it doesn't appear to be working.

I'm also still on Merc/32 4.6 - is this something that is better in 4.72?

 Thanks!

-Norm

ngraziani:

Is there a way to filter an empty FROM field?

Well, you really don't want to reject all '<>' mail from messages as some of those are important.  Have you got Greywall running?  Are you using a safe DNSBL as well?  Both of those will have a big effect on cutting down unwanted mail.

I'm also still on Merc/32 4.6 - is this something that is better in 4.72?

It's a good idea to upgrade even if just for the performance improvements.

You may or may not have noticed my posting about <> From: mail in the Mercury Commuity Support forum.  In my case, I don't see this as a SPAM issue but, rather, an anomaly.  I am only receiving this sort of mail from one (commercial) source and I have given that source a unique To: address for me (as I do for all commercial sources).  This is set up with my ISP (I use the Mercury D distributing client), but there is no reason why these "disposable" addresses can't be set up in Mercury.  I accept all mail which includes the root component of these e-mail addresses without question through a statement in Global Filtering.  This would allow me to distinguish between wanted <> mail and that sent by SPAMmers .... that's if I recieved such mail from SPAMmers, which I don't, unless it's being filtered out by message control rules.

Gordon