accept mail for *?

General discussion re sg.

?

for
1
100%
against
0
No votes
 
Total votes : 1

accept mail for *?

Postby smtpd » Mon Nov 14, 2022 11:13 pm

could SG accept mail for *?
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.
Last edited by smtpd on Wed Nov 16, 2022 7:42 am, edited 47 times in total.
sometime ago, i stopt using SG ``because i wasnt getting any spam.'' what an idiot!
smtpd
 
Posts: 9
Joined: Mon Nov 14, 2022 10:54 pm

inet6

Postby smtpd » Tue Nov 15, 2022 11:13 am

what if SG had inet6?
; example.com. MX mx.example.com.
; mx.example.com. AAAA myip
; myip.ip6.arpa. PTR mx.example.com.
; myip is assigned by the SG ISP

problem.
too much work!
maybe no gain?
inet6 woes?
i cant help sorry : (

whinge.
my ISP WONT upgrade to the 1996 release of the internet
--- but it says i MUST upgrade my software?
Last edited by smtpd on Tue Nov 15, 2022 1:47 pm, edited 4 times in total.
sometime ago, i stopt using SG ``because i wasnt getting any spam.'' what an idiot!
smtpd
 
Posts: 9
Joined: Mon Nov 14, 2022 10:54 pm

wishlist.

Postby smtpd » Tue Nov 15, 2022 12:14 pm

1. incoming to USER@NAME. if NAME MX SG then accept. (but beware open relay spammers.)
2. outgoing from USER@NAME. if NAME SPF SG then accept.
3. (a) create SG ISP to assign inet6 to customers.
(b) monitor inet6 customer assignments for baddies reverse engineering network to launch DOS (denial of service) attack. monitor the forums where these baddies share their DOS exploits to keep SG customers safe.
(c) prosecute baddies for offences against a carrier service.

BUT see ERRATA for (1) and (2) in first post.
Last edited by smtpd on Wed Nov 16, 2022 3:13 am, edited 1 time in total.
sometime ago, i stopt using SG ``because i wasnt getting any spam.'' what an idiot!
smtpd
 
Posts: 9
Joined: Mon Nov 14, 2022 10:54 pm

Re: accept mail for *?

Postby michaeldlr » Tue Nov 15, 2022 5:20 pm

Interesting idea in that it could simplify some of the configuration the admins maintain. So, I would assume that:

* some of the baddies are really surprisingly motivated even for a somewhat obscure service
* if you end up with an effectively open forwarder this will be found quickly and will disrupt our existing service
* once baddies start to find a way to make money from you they get to be very motivited and hard to get rid of

All of which adds up to "we have to add things carefully and be sure they won't disrupt too much". I think the key security risk that has to be overcome is that someone gets you to accept mail on a domain that doesn't want to have mail accepted via spamgourmet. That would have to be protected against by having the person prove they have control of the domain, e.g. in the same way that amazon verifies control of a domain by making the user create a specific key in that domain.

To move towards this idea and make it possible to test whether it can be done safely or not, the first thing is to create a bunch of automated tests which allow us to verify the stability and security of our mail forwarding process which will take some considerable development work. We'd definitely love some help with creating pull requests in github to work towards with that.
michaeldlr
 
Posts: 46
Joined: Sun Jul 10, 2016 5:57 pm

ERRATA Re: accept mail for *?

Postby smtpd » Wed Nov 16, 2022 3:06 am

NOTE: i have changed my idea. see PROBLEM and SOLUTION and CONSEQUENCES.
also FIRST THINGS FIRST.

some of the baddies are really surprisingly motivated even for a somewhat obscure service


(1) makes static DOS list attacks harder.
(3) makes DNS dynamic DOS list attacks harder. but lets forget it for now.

if you end up with an effectively open forwarder this will be found quickly and will disrupt our existing service


(1) checking MX RR prevents SG forwarding random mail.spam@google.com to SG user "spam".
(2) checking SPF prevents SG spoofing from mail.spam@google.com for SG user "spam"

once baddies start to find a way to make money from you they get to be very motivited and hard to get rid of


i only thought about SG users not getting spam, and SG mail not being marked as spam.

I think the key security risk that has to be overcome is that someone gets you to accept mail on a domain that doesn't want to have mail accepted via spamgourmet.

That would have to be protected against by having the person prove they have control of the domain, e.g. in the same way that amazon verifies control of a domain by making the user create a specific key in that domain.


this is what MX RR does.
we need to think of MX records not just as routing information for senders, but as a whitelist of exchanges a domain permits to receive mail on its behalf.
if SG is not on the whitelist it must refuse the mail.

ACTUALLY, i think the real problem is ensuring SG doesnt look bad, which has other problems. MX and SPF checking handle most of this, but i think SG should go even further:

PROBLEM.
the big worry left is, will accepting/sending mail for a domain with a bad reputation damage SGMX by association?
say EXAMPLE.COM is on a blacklist.
it then sets MX SGMX and SPF SGMX.
SGMX is then seen to process mail for EXAMPLE.COM.
could make SGMX 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?

To move towards this idea and make it possible to test whether it can be done safely or not, the first thing is to create a bunch of automated tests which allow us to verify the stability and security of our mail forwarding process which will take some considerable development work. We'd definitely love some help with creating pull requests in github to work towards with that.


it sounds to me like you are wanting to check mail is accepted by big exchanges?
i think this is a different problem?
though understandably one you might want to put in place before making any big changes.
im definitely no expert, but my 2 cents worth:
* check bounces?
* cron job to check blocklists?
* on admins computer, set up accounts with big IMAP & SMTP providers. cron job some mails at random intervals. (problem: might look like spam?)

im not sure this can ever be entirely automated?
* have admins use SG for sending and receiving. hopefully notice if things go spam shaped?
* set up user whinging job to check for blockages?

sorry i cant be more useful.

FIRST THINGS FIRST.
the SPF check would be good to have anyway to keep SG from looking bad. having no SPF "permits" 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")
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.
sometime ago, i stopt using SG ``because i wasnt getting any spam.'' what an idiot!
smtpd
 
Posts: 9
Joined: Mon Nov 14, 2022 10:54 pm


Return to General Discussion

Who is online

Users browsing this forum: No registered users and 17 guests

cron