This is the closest response to what I'm trying to get across. Being that we are a provider, it would not be prudent to handle spam filtering at a global level as who are we to dictate what is and what is not spam to our users.
I personally, would not want to implement what I'm researching. But, the powers that be would like to know....
Typically, there is a catch-all drop for undefined users (554 bounce). Something like a rule "@domain.com > [EMAIL PROTECTED]" which would send all unknown recipient mail to the postmaster. Now, in the event that a domain hasn't setup a drop like this, the mail server will respond with a "554 Unknown User" mail message. THAT message is what they seek to disable. In other words, NO "554 Unknown User" sent, the original message is just discarded. I really disagree with doing this (as would any self respecting admin), but mine is not to question, merely to provide answers.
Will IMGate do this?
yes, in ACL access table, for each left-hand side, you have these actions:
ACTIONS
[45]NN text
Reject the address etc. that matches the pattern,
and respond with the numerical code and text. REJECT optional text...
Reject the address etc. that matches the pattern.
Reply with $reject_code optional text... when the
optional text is specified, otherwise reply with a
generic error response message. DEFER_IF_REJECT optional text...
Defer the request if some later restriction would
result in a REJECT action. Reply with "450 optional
text... when the optional text is specified, other-
wise reply with a generic error response message. DEFER_IF_PERMIT optional text...
Defer the request if some later restriction would
result in a PERMIT action (there is an implied PER-
MIT at the end of each restriction list). Reply
with "450 optional text... when the optional text
is specified, otherwise reply with a generic error
response message.OK Accept the address etc. that matches the pattern.
all-numerical
An all-numerical result is treated as OK. This for-
mat is generated by address-based relay authoriza-
tion schemes. DUNNO Pretend that the lookup key was not found in this
table. This prevents Postfix from trying substrings
of the lookup key (such as a subdomain name, or a
network address subnetwork). HOLD optional text...
Place the message on the hold queue, where it will
sit until someone either deletes it or releases it
for delivery. Log the optional text if specified,
otherwise log a generic message. Mail that is placed on hold can be examined with
the postcat(1) command, and can be destroyed or
released with the postsuper(1) command. Note: this action currently affects all recipients
of the message. DISCARD optional text...
Claim successful delivery and silently discard the
message. Log the optional text if specified, oth-
erwise log a generic message. Note: this action currently affects all recipients
of the message. FILTER transport:destination
After the message is queued, send the entire mes-
sage through a content filter. More information
about content filters is in the Postfix FIL-
TER_README file. Note: this action overrides the main.cf con-
tent_filter setting, and currently affects all
recipients of the message. REDIRECT [EMAIL PROTECTED]
After the message is queued, send the message to
the specified address instead of the intended
recipient(s). Note: this action overrides the FILTER action, and
currently affects all recipients of the message. restriction...
Apply the named UCE restriction(s) (permit, reject,
reject_unauth_destination, and so on).so you'd have to file(s) with all the known users on Imgate:
[EMAIL PROTECTED] ok
and then the "else" would be:
domain.com DISCARD
When trying to resolve "[EMAIL PROTECTED]" if will query for:
user@
then
[EMAIL PROTECTED]
then
domain.com
... so unknown users "fall through" to the "else" of domain.com and get DISCARDed silently, ouch!
Len
To Unsubscribe: http://www.ipswitch.com/support/mailing-lists.html List Archive: http://www.mail-archive.com/imail_forum%40list.ipswitch.com/ Knowledge Base/FAQ: http://www.ipswitch.com/support/IMail/
