Re: smtpd_recipient_restrictions in mongodb?
Exactly. Here a typical row | 1382959 | nelly_cab...@gmail.com | REJECT Recipient address rejected for policy reasons | 2018-11-04 01:49:33 mysql> describe virtual_sender_access ; +---+-+--+-+-+-+ | Field | Type| Null | Key | Default | Extra | +---+-+--+-+-+-+ | id| int(11) | NO | PRI | NULL| auto_increment | | source| varchar(64) | NO | MUL | | | | access| varchar(64) | NO | | | | | created_on| timestamp | NO | | -00-00 00:00:00 | | | check_bounce | int(11) | NO | | NULL| | | last_modified | timestamp | NO | | CURRENT_TIMESTAMP | on update CURRENT_TIMESTAMP | +---+-+--+-+-+-+ All rows use this bounce "REJECT Recipient address rejected for policy reasons". El mar., 14 de jul. de 2020 a la(s) 10:01, Ralph Seichter ( ra...@ml.seichter.de) escribió: > * SysAdmin EM: > > > query = SELECT access FROM virtual_sender_access WHERE source='%s' > > You wrote that you only store nonexistent sources. In that case, the > value of the "access" column should always be something that indicates > "access denied", possibly a constant value across all entries? If so, > > SELECT 'restricted' as access FROM ... > > should provide a way of reducing the DB load in a very small way, as > only an index scan would be required. However, that only saves one read > operation per lookup and therefore may not help you much. > > I am still unconvinced that the type of data you are storing provides a > good way to achieve your goal. > > > Does postfix have support for mongo database? > > Following Wietse's rule of "if it is not documented it is not supported" > and the content of http://www.postfix.org/DATABASE_README.html , the > answer should be no. > > -Ralph >
Re: smtpd_recipient_restrictions in mongodb?
* SysAdmin EM: > query = SELECT access FROM virtual_sender_access WHERE source='%s' You wrote that you only store nonexistent sources. In that case, the value of the "access" column should always be something that indicates "access denied", possibly a constant value across all entries? If so, SELECT 'restricted' as access FROM ... should provide a way of reducing the DB load in a very small way, as only an index scan would be required. However, that only saves one read operation per lookup and therefore may not help you much. I am still unconvinced that the type of data you are storing provides a good way to achieve your goal. > Does postfix have support for mongo database? Following Wietse's rule of "if it is not documented it is not supported" and the content of http://www.postfix.org/DATABASE_README.html , the answer should be no. -Ralph
Re: smtpd_recipient_restrictions in mongodb?
The user database is set up because my clients, some bad users, send mass mailings to non-existent accounts, such as hotmail, gmail, which usually measure the number of IP bounces. Also sometimes there are cases where the PC or mobile device is infected with a virus and they use the email account to send spam, so I add those accounts that they sent to my list because they can see spam trap. the database has maintenance, the accounts within it are cleaned as I check them with another system, I only clean those that exist. here I add some info from the table mysql> desc virtual_sender_access; +---+-+--+-+-+-+ | Field| Type | Null | Key | Default| Extra | +---+-+--+-+-+-+ | id | int(11)| NO | PRI | NULL | auto_increment | | source | varchar(64) | NO | MUL || | | access | varchar(64) | NO ||| | | created_on | timestamp | NO || -00-00 00:00:00 | | | check_bounce | int(11)| NO || NULL | | | last_modified | timestamp | NO || CURRENT_TIMESTAMP | on update CURRENT_TIMESTAMP | +---+-+--+-+-+-+ 6 rows in set (0.00 sec) mysql> show index from virtual_sender_access ; +---++--+--+-+---+-+--++--++-+ ---+ | Table| Non_unique | Key_name | Seq_in_index | Column_name | Collation | Cardinality | Sub_part | Packed | Null | Index_type | Comment | Index_comment | +---++--+--+-+---+-+--++--++-+ ---+ | virtual_sender_access | 0 | PRIMARY | 1 | id | A|4225535 |NULL | NULL | | BTREE || | | virtual_sender_access | 1 | source | 1 | source | A|4225535 |NULL | NULL | | BTREE || | +---++--+--+-+---+-+--++--++-+ ---+ 2 rows in set (0.00 sec) I would like to know if I can use mongo in the smtpd_recipient_restrictions parameter anyway. Thank you. Regards, El lun., 13 de jul. de 2020 a la(s) 18:05, Ralph Seichter ( ra...@ml.seichter.de) escribió: > * SysAdmin EM: > > > I use a suppression list where I block domains and email accounts that > > don't exist to prevent the reputation of my IP addresses from going > > down. [...] The table currently has 4 million rows, so I am looking > > for a faster database engine than MySql. > > Can you clarify for me: You try to maintain a database for domains that > do not exist and email accounts that do not exist? How would that work? > Both the number of nonexistent domains and and accounts are, while not > infinite, huge. Why not list the domains and accounts that do exist? > These numbers are definitely finite. > > As for your choice of database: I am a fan of MongoDB because of its > capability of storing unstructured data, but here your data does have a > well-defined, uniform structure. If you use a proper index, MySQL or > similar relational databases should be quick as blazes. > > -Ralph >
Re: smtpd_recipient_restrictions in mongodb?
* SysAdmin EM: > I use a suppression list where I block domains and email accounts that > don't exist to prevent the reputation of my IP addresses from going > down. [...] The table currently has 4 million rows, so I am looking > for a faster database engine than MySql. Can you clarify for me: You try to maintain a database for domains that do not exist and email accounts that do not exist? How would that work? Both the number of nonexistent domains and and accounts are, while not infinite, huge. Why not list the domains and accounts that do exist? These numbers are definitely finite. As for your choice of database: I am a fan of MongoDB because of its capability of storing unstructured data, but here your data does have a well-defined, uniform structure. If you use a proper index, MySQL or similar relational databases should be quick as blazes. -Ralph
