>the point is that these nets are not for public use, so using them is not
>expected behavior. So don't use them if you wante to receive expected
>treatment.
The expected behavior for private networks is to use RFC1918 nets, which
I've excluded from the my bogon list, or public IPs.
========================
The general idea is that we are trying to raise non-credentials from "any
mail server set up anywhere and any way can send anything anything to
anybody" to an increasing level of RFC/recommended/best practice
credentials. The credentials are enforced by SMTP and cleanup
restrictions. ("If you don't present the credentials I insist upon, I do
not accept your mail")
1. sending IP (MTA SMTP client to our SMTPD server)
have a PTR record (and it would be better if PTR hostname matched an A
record).
not be blacklisted as abusive (RBL, etc)
(sending IPs in the Received: headers also meet same credentials (eg,
bogon) as SMTP client)
Sending IP not be in "subscriber" networks.
2. HELO command
is executed (helo required).
helo hostname is present
.. valid characters
.. fully qualified (forward) domain name (not an IP). (Is not or doesn't
contain an IP address)
... has A and/or MX records.
3. MAIL FROM:<[EMAIL PROTECTED]> (envelope sender domain)
fully qualified sender or null sender
ESD has A or MX records
ESD is not "RFC ignorant"
ESD for monkeys' "frequently forged domains" must have matching PTR and A
records.
ESD must not be in blacklist of abusive ESD (spamdomains, imgfx, etc)
[EMAIL PROTECTED] domain must accept return mail (sender_address_verification)
( ESD publishes SMP/SPF DNS records. )
4. RCPT TO:<[EMAIL PROTECTED]>
ERD have A and/or MX record
ERD have valid characters
ERD be fully qualified
MX for ERD accept mail for recipient (recipient_address_verification)
DATA Content:
5. headers:
max length restricted
some restrictions on 8-bit characters in Subject:
Received: headers contain no bogon IPs.
6. total message: max size
7. attachments: "dangerous" attachments not permitted.
So you get the general idea. you should be able to go through you postfix
config and express your policies in simple terms.
Then, there are the SMTP/SMTPD timeout restrictions and soft/hard error
limits. etc, etc.
Len