[Mimedefang] Re: On pinheaded ISP's (sort of OT)

[John Rudd]

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.