On 4/23/2010 6:10 AM, oliver wrote:
On Thu, 22 Apr 2010 19:06:59 -0500, Noel Jones<njo...@megan.vbhcs.org>
wrote:
On 4/22/2010 6:17 PM, Oliver Schinagl wrote:
Here's what I have in my postconf now:
mydomain = example.com
myhostname = foo.example.com
mynetworks_style = host
OK, you're not defining mynetworks, permit_mynetworks should
only allow your host's IPs. That's fine.
I simply assumed, it's probably best to allow no one but localhost to mail
unauthorized.
If that's your intention, it's probably better to explicitly
state:
mynetworks = 127.0.0.1
Most people also list their local network here, but that's not
a requirement.
relay_domains = pgsql:/etc/postfix/pgsql/pgsql-relay-domains-maps.cf
Using relay_domains without relay_recipient_maps is strongly
discouraged. Your queue will get clogged with undeliverable
mail and eventually you'll be blacklisted as a backscatter source.
I went looking up relay_recipient_maps and from what I gather, all the
users that are in my user table on the other end would have to be here as
well? This basically means my database backend would/could be
identical/synchronized then with just the backupmx flag on the domain
reversed?
Yes, the recipient list needs to be shared.
But really, the idea of third-party backup MX is long dead.
Better to not offer the service to others nor use it yourself.
Without very close cooperation between you and the other
party, one of you is going to be a backscatter source.
I can understand this working in my specific setup, where I admin
both servers, but what if I would be a backupmx for a domain where I do not
know the users from? E.g. My friend runs his own mailserver, and he likes
me to be his backupmx; I'm perfectly fine with that, but I rather not have
to keep his userbase in sync with my userbase, or did I completly
missunderstand? I saw specifying @domain is bad, what about a catchall?
*...@backupmxdomain.com or are those identical in that sense? Or am I
completely missing the point on this one.
If you accept mail for some other system, and then they refuse
it, it makes you a backscatter source.
http://en.wikipedia.org/wiki/Backscatter_%28e-mail%29
http://www.postfix.org/BACKSCATTER_README.html#wtf
This is about when you're a victim of backscatter, but you
really don't want to be the source -- you will get blacklisted.
If the remote system will never reject or bounce back mail you
send them, I suppose you don't need a recipient list. But
there is at least some evidence that systems that accept
catch-all addresses are spam magnets.
If the receiving system rejects unknown recipients during
SMTP, you can let postfix build a list of known recipients for
you.
http://www.postfix.org/ADDRESS_VERIFICATION_README.html#recipient
but this doesn't help if the remote system rejects or bounces
back mail it thinks is spam.
Also, re-reading it again, postfix will look up the string, but doesn't use
the result, e.g. something like select * from backupmxtable where
domain=%u; would result in a positive hit and all mailboxes from that
domain, but that would also make me become a source of backscatter mail
(what is that anyway)? I would assume that my postfix server would accept
the mail, then forward it to the other host and deliver it there.
The problems start when the other host either rejects mail, or
bounces it back to you. You must not allow that as a normal
occurrence. An occasional bounce is probably unavoidable, but
you should do whatever you can to avoid them.
smtpd_banner = $myhostname NO UCE ESMTP
That must be
smtpd_banner = $myhostname ESTMP comments...
I assume the order matters here? I figured the NO UCE bit would be totally
useless and totally ignored anyway, but hey, it would be there for all to
see.
ESTMP must be the second field, you can put whatever else
after that. I suppose the notice might do some good if you
decide to sue a spammer someday.
smtpd_client_restrictions = permit_mynetworks,
permit_sasl_authenticated, permit_mx_backup, reject_rbl_client
zen.spamhaus.org, reject_rbl_client cbl.abuseat.org, reject_rbl_client
bl.spamcop.net
"permit_mx_backup" is evil and disabling your RBL lookups.
Ah! now we're onto something. But why? is it filling in more then my backup
mx domains here? I assume setting up relay_domains (properly) as above
allows mail from my backups to arrive normally without consulting
smtpd_client_restrictions?
permit_mx_backup also implies permit_auth_destination. No
checks make sense after that other than "reject" -- the only
mail that will still be processed at this point are unauth
relay attempts.
http://www.postfix.org/postconf.5.html#permit_mx_backup
But really, the idea of a third-party backup MX is long dead,
killed by spammers. Better to not offer the service to others
nor use it yourself.
smtpd_recipient_restrictions = permit_mynetworks,
permit_sasl_authenticated, permit_mx_backup, check_policy_service
inet:127.0.0.1:2525, reject_unauth_destination
Remove permit_mx_backup, it's disabling all your other checks.
As above, I don't understand how here either :)
See above.
smtpd_sasl_security_options = noanonymous
Caution, this setting allows plain text passwords to be sent
unencrypted. Safer (but harder for testing and maybe less
compatible):
smtpd_sasl_security_options = noplaintext, noanonymous
smtpd_sasl_tls_security_options = noanonymous
Would base64 encoded usernames/passwords count? I'm not sure what roundcube
does in that regard, then again, it doesn't matter as it is running locally
anyway; and it has an option to properly login when sending messages
remotly I belive.
Plain-text does not always mean human-readable. Base64 text
is trivially decoded and is considered plain text.
-- Noel Jones
