Roman Medina-Heigl Hernandez wrote:
Noel Jones escribió:
Roman Medina-Heigl Hernandez wrote:
Hello,
I don't want my mail queue to fill due to fake mail (spam) so I'd like to
reject as much mail as I could at the smtp stage (avoiding mail entering
into my queues). My setup is multi-domain (vdomains) and it's working
reasonably well for my hosted domains ("real") but not for those being
"aliased". The problem (I guess) if that I'm using "wide" aliasing so I
have an alias table (virtual_alias_maps) of the form:
@aliasdomain.com @realdomain.com
(no users are being especified).
Wildcards break recipient validation.
So all possible recipients at aliasdomain.com are being taken as
"existing", and thus not being rejected by reject_unlisted_recipient
rule.
This is expected behaviour (I guess), but I'm wondering whether there is
any elegant way to solve the problem without having to create one-to-one
aliases such as: us...@aliasdomain.com us...@realdomain.com,
us...@aliasdomain.com us...@realdomain.com, etc.
Do you know a cute way to solve this? Thank you.
Use 1-1 mappings. Use a little script and a Makefile to let the
computer build the aliased domain from the real domain list you already
maintain. Size of the table is not an issue.
Your postconf output looks OK.
Yes, all tasks can usually be automatized but sometimes it's good to
simplify things. I don't know much about postfix internals, I suppose this
is a design decission, I mean, aliases are "resolved" at later stages, but
perhaps it could be good to have a simple check at the smtp stage in a way
that if all targets of a given alias entry are local domains, then Postfix
would evaluate $local_recipient_maps against those local domains. Same
apply for other classes (such as virtual by checking
$virtual_mailbox_maps). Of course if an alias points to another alias, this
second alias could be resolved in the same way. In other words, the idea is
to resolve the alias entry until you reach a point were you cannot know
which users do a domain have for sure so the only choice is to add the mail
to queue and let the other postfix subprocesses makes their job.
If all final recipients can be checked against its corresponding map (i.e.
you know for sure if they exist or not), reject_unlisted_recipient will be
honored. If not, let the mail drop into the queue (for instance if you have
an alias to an external domain; or if you have a mix of destination domains
related to one alias entry: "hosted" and external, eg).
I think it makes sense... and it could be an useful feature. It would be
nice if Wietse could comment on this.
He has, more than once. Check the archives.
Short summary -
Recipient validation is an add-on feature not present in the
original postfix design (such a feature wasn't considered
important 10+ years ago). Adding recursive recipient
validation is a worthy goal and may be addressed in a future
redesign of postfix. This would probably involve a new
address resolution daemon and redesign of the mail flow
through postfix, not a trivial task.
Back to my comments:
I've found it convenient to create a Makefile that contains
all my various maps and user tables. When I make a change to
any of the source files, I just type "make" and everything is
rebuilt without me having to do much thinking about which
tables need to go where and what data affects more than one
table. Even if postfix did have recursive recipient
validation, I would still use this for my local
administration. Here's a sample to help you get started:
http://www.postfix.org/DATABASE_README.html#safe_db
--
Noel Jones
