[exim] Rejecting non-RFC compliant email addresses?

Góra strony
Delete this message
Reply to this message
Autor: Gregg Berkholtz
Data:  
Dla: exim-users
Temat: [exim] Rejecting non-RFC compliant email addresses?
I've begun receiving emails with quotes or slashes in the recipient's
address, and my exim daemon/config (v3.35) is accepting the addresses as
valid - to a point... My understanding was that such characters, within
email addresses, should not be treated as valid.

I believe the root issue lies with how the rewrites are behaving.

The rewrite rule:
*@lsearch;/etc/exim/exim.local_domains "${lookup ldap{ldap://ldapmaster.mydomain.com:389/ou=People,dc=mydomain,dc=com?mail?sub?(mailAlias=${quote_ldap:$local_part@$domain})}{$value}fail}" tTbc

The above rule works great, when an address without quotes or slashes is
passed to exim. Though when an address with quotes/slashes is passed to
exim, the following error occurs, and instead of exim rejecting the
address/email, it accepts them:
Expansion of ${lookup ldap{ldap://ldapmaster.mydomain.com:389/ou=People,dc=mydomain,dc=com?mail?sub?(mailAlias=${quote_ldap:$local_part@$domain})}{$value}fail} failed while rewriting: lookup of "ldap://ldapmaster.mydomain.com:389/ou=People,dc=mydomain,dc=com?mail?sub?(mailAlias=%5C%22someuser%5C%22%40mydomain.com)" gave DEFER: ldap search initiation failed

When this occurs, email delivery is then deferred for all users under
the associated domain, and the message with the invalid address sits in
the queue. I've gone as far as trying, and failing (so-far), to develop
a rewrite regex via pcretest to just strip unwanted RCPT characters at
SMTP time, though I'm not sure that's the right avenue to continue down.

Is there any way to make the rewrite fail/skip in the event of this LDAP
lookup defer? Is there a different/better way to do this rewrite via
LDAP (it's for alias lookups)? Is it even possible to use a rewrite
regex to strip unwanted characters from email addresses at SMTP time
(ie: when using the rewrite "S" flag)?

Any suggestions are greatly appreciated.

Thank you,
Gregg Berkholtz