right now i think it says it "wont relay" messages for my own domain.
i would like to not have to ask root to add any domains.
for.
* user can add domain. (RR = relay ready.)
* beat some baddies using DOS lists.
against.
* SG might forward spam targeting open relays to users?
--- for: ensure RCPT TO MX SG in DNS.
--- for: user must enable "receive to *"
* reply address masking could wreck SG.
--- for: ensure MAIL FROM SPF SG in DNS.
--- for: or disable for *
* maybe some servers might test for and ignore open relays.
--- for: see first * point
--- for: maybe greylist RCPT TO
* doesnt beat some baddies.
flaw?
my working assumption is that the DOS baddies
* are lazy
* cant program very well
* arent very smart (so dont go giving them ideas?)
* arent insane zealots (likely my most flawed assumption)
ERRATA.
NAME REPUTATION PROBLEM.
will accepting/sending mail for a domain with a bad reputation damage SG by association?
say EXAMPLE.COM is on an SMTP blacklist.
it then sets MX SG and SPF SG in DNS.
SG is then seen to process mail for EXAMPLE.COM.
could make SG look bad?
keep in mind that incoming mail will go through big mail providers.
SOLUTION.
SG still needs to maintain a whitelist. to get on the whitelist, NAME must
* MX SG
* not be on any SMTP blacklists
run a cron job that moves bad names to a blacklist.
CONSEQUENCES.
the blacklist check is too much to do on receipt. so it is done at user request.
must still check SPF when sending.
maybe refuse sending altogether if we want to be careful?
ADDENDA.
SPF REPUTATION PROBLEM?
some users might want to send mail from their domain without going through SG.
if they explicitly permit a blacklisted sender, this might make their domain look very bad?
might this make SG look bad by association?
PARTIAL SOLUTION?
simply ensuring their domain isnt blacklisted might fix this.
also i think SG should at least refuse to send mail unless the SPF is one of
* "v=spf1 include:spamgourmet.com -all"
* that of spamgourmet.com
TODO.
FIRST THINGS FIRST.
the SPF check would be good to have anyway to keep SG from looking bad.
a legacywhitelist could be kept that would also allow no SPF (but not SPF without SG), for domains like dfgh.net that are yet to configure SPF.
having no SPF looks bad to big mail providers. it allows spoofing. this might be handy for some SG users, but looks spammy. users should use their own domain with SPF. (hint for users: "v=spf1 include:spamgourmet.com mystaticip mydynamicip -all")
counterpoint: a mail provider would have to really suck to treat no SPF as "~all" instead of "mx ~all". except: they often do really suck.