Pegasus Mail & Mercury

Does Mercury/32 currently have the ability to do DNS resolve on the sender's domain and reject the message it if it does not resolve?

No it does not.

---

Thomas R. Stephenson
San Jose, California
Member of Pegasus Mail Support Team

tuaris:

Does Mercury/32 currently have the ability to do DNS resolve on the sender's domain and reject the message it if it does not resolve?

No, because this would lead to too much technical support trying to explain to people why it failed. It's a very unreliable test, one which can fail for any number of reasons (for example, something like 60% of domains in Asia are not have reverse-resolvable).

If someone would care to make a compelling case for some kind of approach or method with zero or near-zero failure possibility (so we wouldn't get saddled with a whole lot of unnecessary technical support) I'll happily consider it.

Cheers!

-- David --

David Harris:

tuaris:

Does Mercury/32 currently have the ability to do DNS resolve on the sender's domain and reject the message it if it does not resolve?

No, because this would lead to too much technical support trying to explain to people why it failed. It's a very unreliable test, one which can fail for any number of reasons (for example, something like 60% of domains in Asia are not have reverse-resolvable).

And this is a problem because...?

Seriously...  Quite beyond the fact that I (and, I suspect, most Mercury users) have essentially zero interent in receiving mail from Asia because it is near-guaranteed to be spam, if whomever admins the sending server (regardless of where it is located) is that lazy/incompetent/malicious/whatever, then I just as near-certainly do not want traffic from them.

If someone would care to make a compelling case for some kind of approach or method with zero or near-zero failure possibility (so we wouldn't get saddled with a whole lot of unnecessary technical support) I'll happily consider it.

I think this is simply a matter of how you define "failure" in this context.  For example, I would NOT consider the rejects of those " 60% of domains in Asia" to be failures of Mercury or my server; but rather, as failures of the sending domain to do their job correctly -- and that's THEIR problem, not mine.

Frankly, the inability to do this and other checks on the validity/acceptability of incoming traffic -- particularly in time to issue a 5xy rejection, as opposed to after the mail has already been accepted (by which point, my only recourse is top drop it on the floor) -- is one of the reasons I've been strongly considering abandoning Mercury in favor of a *nix-based MTA such as Courier or Postfix.  In fact, my primary motivation for joining this forum was to address that very point; but I'll do so in a separate post where I can give it its just due -- so enough of that for now.

Sailor21:

And this is a problem because...?

Seriously...  Quite beyond the fact that I (and, I suspect, most Mercury users) have essentially zero interent in receiving mail from Asia because it is near-guaranteed to be spam, if whomever admins the sending server (regardless of where it is located) is that lazy/incompetent/malicious/whatever, then I just as near-certainly do not want traffic from them.

Well, my clients, (and, I suspect, a LOT of Mercury users) have an increasing interest in receiving mail from (and doing business in) Asia.

I think this is simply a matter of how you define "failure" in this context.  For example, I would NOT consider the rejects of those " 60% of domains in Asia" to be failures of Mercury or my server; but rather, as failures of the sending domain to do their job correctly -- and that's THEIR problem, not mine.

Frankly, the inability to do this and other checks on the validity/acceptability of incoming traffic -- particularly in time to issue a 5xy rejection, as opposed to after the mail has already been accepted (by which point, my only recourse is top drop it on the floor) -- is one of the reasons I've been strongly considering abandoning Mercury in favor of a *nix-based MTA such as Courier or Postfix.  In fact, my primary motivation for joining this forum was to address that very point; but I'll do so in a separate post where I can give it its just due -- so enough of that for now.

I prefer to classify spam based on content rather than dubious methods of ascertaining the reputation of the sending client.

If this requirement is that important to you, then you are free to pick a tool that implements it, be it and SMTP proxy before Mercury, or a MTA that includes it.

Or you could just blacklist the world and whitelist the people you want mail from  

dilberts_left_nut:

Sailor21:

And this is a problem because...?

Seriously...  Quite beyond the fact that I (and, I suspect, most Mercury users) have essentially zero interent in receiving mail from Asia because it is near-guaranteed to be spam, if whomever admins the sending server (regardless of where it is located) is that lazy/incompetent/malicious/whatever, then I just as near-certainly do not want traffic from them.

Well, my clients, (and, I suspect, a LOT of Mercury users) have an increasing interest in receiving mail from (and doing business in) Asia.

In which case, you need not enable that particular feature; or at minimum, you could configure it (such as via whitelisting) in such as way as to not reject mail from those sources you already know you wish to correspond with.  Or better yet, convince your correspondents to operate their MTAs in a competent and responsible fashion, or obtain service from someone who does.  But none of this obviates the inherent value of the feature itself, particularly for the vast majority of the folks who would derive benefit from it.

I prefer to classify spam based on content rather than dubious methods of ascertaining the reputation of the sending client.

That is fundamentally bass-ackwards.

It's not about content; it's about conSENT. It is NEVER appropriate to consider content in an attempt to determine whether that a given piece of mail is or is not spam, except for the very narrow purpose of determining if that mail is commercial/advertising/promotional in nature (and sometimes not even then).  Further, to consider the individual message AT ALL before determining that the source of the traffic has indeed passed muster (by whatever criteria one may care to apply to that) is at the least premature.  Think about it:  If for whatever reason the source is not acceptable, then the individual message simply doesn't matter.  If said source is (currently) considered acceptable, THEN we can look at the individual message to determine (on it's on merits, or lack thereof, independent of the source) if it is acceptable.  It follows from this that if too many (where "too many" can be as little as "> 0", depending on one's particular needs and priorities) unacceptable messages come from a given source, that is a valid reason to subsequently decide that the source is no longer acceptable, thus saving us the need to even bother considering future individual messages from that source.

If this requirement is that important to you, then you are free to pick a tool that implements it, be it and SMTP proxy before Mercury,

Which would rather obviate the point in running Merc.

or a MTA that includes it.

As I mentioned previously, that is under consideration.  I'd prefer to avoid having to make that move, at least right now; but if push comes to shove...

Or you could just blacklist the world and whitelist the people you want mail from

I realize you're being a bit facetious here; but that is not a fundamentally unreasonable approach.  To take it literally is rather too restrictive for most applications.  But the basic premise that the sender MUST meet the recipient's requirements in order to ensure delivery is perfectly valid.