Kevin A. McGrail wrote:
If you can't reject during the initial SMTP phase, then your NDR's of
spam,
with their possible forged envelope addresses, will also be spam. So,
if you
can't drop at the initial conversation, or it is relayed from a backup
MX, it
is your message, and your problem. Just don't generate NDR's. If you
can't
return at SMTP, you will need to drop it.
We'll politely disagree because I am doing my best to reject mail
including having backup servers query primary servers for valid email
addresses but when the primary server is down, we MUST queue mail up on
our servers. If people choose to view that as us being the source of
SPAM, then they are negating the entire point of having backup MX's for
when stuff hits the fan.
IMO:
A) My collection of mail servers as a whole is one big box. I don't
trust anything outside of the box, wrt to spam and viruses, but I do
trust everything inside of that box. And each host in that box has the
necessary information and configurations for making rejection decisions.
B) "Front-line" hosts here refers to all MX/routing/scanning hosts,
whether they are primary MX hosts or secondaries. All such hosts have
the same software for scanning, the same list of valid addresses, and
the same configurations for all of their software. They do not scan nor
reject messages that come from the back-line hosts.
C) "Back-line" hosts are the IMAP/POP/Webmail servers, which also accept
authenticated email via SMTP-AUTH. As a result, they also do anti-virus
scanning (but not anti-spam scanning) for any messages that do NOT come
from the front-line hosts.
So:
If a front-line host accepts the message, then the message will be
delivered to the user. Period. If it turns out that later, that
message would have been rejected for some reason, (such as a change in
anti-virus signatures between the time the front-line hosts accepted the
message and when the back-line hosts received it, which could now have
caught that messsage, etc.: too bad. The message was accepted. It is
now "inside the box" and will not be re-evaluated for rejection. (it
might be re-evaluated for spam marking, if we add a per-user bayesian
scanner for the delivery phase within the back-line servers, so that
they can train their own filters; but the anti-spam engine that decides
to reject or not does not use per-user information; but it will not be
re-evaluated for rejection)
So the scenario you present can't happen. The front-line servers (even
a very low MX host) will not accept a message for a user/list that
doesn't exist on the back-line hosts. So even if the back-line hosts
are down, it doesn't matter. If I were to make it such that the
front-line hosts were less-state-ful about destination addresses (ie.
move to the milter-ahead type model, that mimedefang also supports),
then I would say: if the back-line or higher-priority MX's are unable to
tell me if a destination is valid or not, then the low-priority MX
should tempfail that destination address.
It also means we don't drop messages ... which I agree is INCREDIBLY
irresponsible.
Reject at the border, and only at the border ... or mark or clean and
then deliver. Those are the only two options I allow.
The ONLY time we accept a message and then bounce it: the user's account
is over quota. And I'm working on how to reject at the front-line if
the destination is over-quota.
_______________________________________________
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
