Les Mikesell wrote:
John Rudd wrote:
Accepting a message that your own scanners say contains
spam/virus/bad-content, and then crafting a bounce message for it
instead of delivering it, is a bad practice and should never be done.
Dropping valid messages without notifying the sender is an even worse
practice.
Dropping without notifying _anyone_ is "an even worse practice". You
don't have to notify the sender, as long as you notify the recipient
(and visa versa).
"Bad content" is a fairly arbitrary concept.
The term is rather arbitrary. What I meant by it is not: messages that
have malformed MIME parts, messages that have attachments whose filename
or filetype I don't like, phishing messages (as determined by ClamAV),
and messages with HTML tags I don't like (IFRAME, OBJECT, etc.).
It's easier, though, to just say "bad content" than to write all of that
out.
> Can you honestly claim
that you are
anywhere near 100% correct in your determination of that?
I don't need to. I either reject or mark+deliver. If I'm wrong in my
determination, it ends up in someone's mail folder so they know about it.
2) Don't accept it. Reject it. Give an SMTP 4xx or 5xx result, with
a reason for why you didn't accept it. Let the submitting (SMTP
client) host figure out what to do with it from there. Most likely
it's a spam/virus bot, and the problem is resolved.
MimeDefang can do this; I don't think Mailscanner can.
No, Mailscanner can't. That's one of the reasons I switched :-)
You'll notice that neither of these is "bounce it".
In a practical sense, it is. If the other end of the SMTP conversation
is an
RFC-conforming server, your 5xx rejection forces it to construct a bounce.
If it is a virus, it will probably drop on the floor.
No, a rejection is not the same as a bounce. Not even in a practical sense.
You can't ever control what another MTA is going to do with a message.
And, more importantly, it's not your job to know/care what it's going to
do with that message. It's only your job to deal with the things you do
actually control: which messages you will accept or reject, and what
you're going to do with the ones you've accepted.
Rejecting is not the same as bouncing. Ever. Because you don't know
what that MTA is going to do with the rejected message AND it is not
your responsibility to know what it is or is not going to do with the
rejected message.
Rejecting is saying "I will not take responsibility for the message".
Bouncing is saying "I took responsibility for the message, and now I've
got to try to send it back."
The two are worlds apart.
On a practical level, more likely than not, the source of the message
was a directly connected spambot, virusbot, or spam-house (because
you're not accepting connections from open relays, right?). In those
cases, rejecting the message does not cause the submitting SMTP client
to create a bounce message. They just forget the message and move on.
_______________________________________________
NOTE: If there is a disclaimer or other legal boilerplate in the above
message, it is NULL AND VOID. You may ignore it.
Visit http://www.mimedefang.org and http://www.roaringpenguin.com
MIMEDefang mailing list [email protected]
http://lists.roaringpenguin.com/mailman/listinfo/mimedefang
