Bill Casey wrote:
> I am running Exim on a Fedora server. Today I have been encountering
> trouble sending e-mail to an address that contains a hyphen. E-mails
> to this address from my gmail account work fine - but whn they
> originate on this server they appear to be delivered to the SMTP
> server - and then disappear. Here are a couple of log lines - 2
> accounts at the same destination server -
>
> 2008-05-17 23:02:28 1JxZAJ-0000Ad-M1 => not-real@???
> R=lookuphost T=remote_smtp H=mxmta.sympatico.ca [67.69.240.19]
> 2008-05-17 23:04:12 1JxZBz-0000Cj-KB => notreal@???
> R=lookuphost T=remote_smtp H=mxmta.sympatico.ca [67.69.240.18]
>
> Note - both of these accounts are uniqie, and do exist - but the
> address with the hyphen disappears into thin air - no error message,
> no bounce.
>
> Any ideas what could be causing this?
>
Most likely culprit is a bent REGEXP rule in an anti-spam acl.
If, as you state, you can reach that address from a server other than
your Exim one, then it is indeed your own server that you need to look into.
To find it:
1) use Exim's superb debug facility on a test message
AND/OR
2) Temporarily set 'log_selector = +all' so your logs will show the
fine-detail of specific router/transport handling it AND far-end
response (or NOT).
3) Set up the same sort of account on your own box
(ex: test-me@<your_own_domain>.<tld>
-- Send an 'acl_not_smtp' class message by use of an on-box binary from
a shell account, either by calling Exim directly or:
-- mail -s Test test-me@<your_own_domain>.<tld>
Test
.
- either of which will bypass the acl_smtp_<whatever> rules.
If it succeeds, then your blockage is in an acl_smtp_<whatever> rule.
NB: If using a 'computed' expression for REGEXP, the hyphen may or may
not 'visibly' appear in the rule as such. You may be blocking a range of
characters by binary values that happens to include it.
FWIW - the hyphen *is* RFC-permissable. Most MLM software relies heavily
on these, ('list-owner' et al) so blocking is not ordinarily wise.
HTH,
Bill
