<commit_before>#summary How to get mail into SubEtha in the first place

= Receiving Mail =

You've followed the InstallGuide and now you have a properly configured instance of SubEtha running on your host.  Only one question remains - how does mail get into SubEtha in the first place?

There are four general strategies, arranged here in order of increasing complexity:

== Take All Mail ==

The simplest solution is to run SubEtha's SMTP server on port 25 and accept all mail for your domains that contain lists.  Mail for addresses that are not SubEtha lists will be rejected.

The advantage of this approach is that you don't need to touch the configuration of Postfix Exim, etc.  Create your MX records, run SubEtha, and go.  On Unix-derived systems, you might need some help UsingPort25.

The downside of this approach is that you cannot have mailing lists on the same domain that you have personal mailboxes; for example, you cannot have <EMAIL> and <EMAIL>.  You would need to have @example.com point to your normal MTA and create one or more separate domains for lists, for example @lists.example.com.

== Use Fallback Host ==

SubEtha 2.x introduces a new way to handle mail.  If you Take All Mail as above, you can also configure a "fallback host" to which SubEtha will direct all mail which is not intended for SubEtha.

Let's say you have several lists running @example.com but also have personal mailboxes @example.com running under your local MTA (say, Postfix).<commit_msg>Got rid of main header<commit_after>#summary How to get mail into SubEtha in the first place

You've followed the InstallGuide and now you have a properly configured instance of SubEtha running on your host.  Only one question remains - how does mail get into SubEtha in the first place?

There are four general strategies, arranged here in order of increasing complexity:

== Take All Mail ==

The simplest solution is to run SubEtha's SMTP server on port 25 and accept all mail for your domains that contain lists.  Mail for addresses that are not SubEtha lists will be rejected.

The advantage of this approach is that you don't need to touch the configuration of Postfix Exim, etc.  Create your MX records, run SubEtha, and go.  On Unix-derived systems, you might need some help UsingPort25.

The downside of this approach is that you cannot have mailing lists on the same domain that you have personal mailboxes; for example, you cannot have <EMAIL> and <EMAIL>.  You would need to have @example.com point to your normal MTA and create one or more separate domains for lists, for example @lists.example.com.

== Use Fallback Host ==

SubEtha 2.x introduces a new way to handle mail.  If you Take All Mail as above, you can also configure a "fallback host" to which SubEtha will direct all mail which is not intended for SubEtha.

Let's say you have several lists running @example.com but also have personal mailboxes @example.com running under your local MTA (say, Postfix).
{'fraction_non_alphanumeric': 0.040417649040080834, 'fraction_numerical': 0.003368137420006736, 'mean_word_length': 4.284697508896797, 'pattern_counts': {'":': 0, '<': 7, '<?xml version=': 0, '>': 7, 'https://': 0, 'lorem ipsum': 0, 'www.': 0, 'xml': 0}, 'pii_count': 0, 'substrings_counts': 0, 'word_list_counts': {'cursed_substrings.json': 0, 'profanity_word_list.json': 0, 'sexual_word_list.json': 0, 'zh_pornsignals.json': 0}}
{'dir': 'git-commits-cleaned', 'id': '5786814', 'n_tokens_mistral': 766, 'n_tokens_neox': 731, 'n_words': 485}