Mailing List Archive

percent hack relaying help, please
Hi Exim folks,

I have a default satellite configuration that is relaying via percent
hack. A copy of the exim.conf file is attached (sanitized).

Any help in finding out why this host is relaying would be greatly
appreciated. Please CC: me on replies, as I am not (yet;-) subscribed
to this list.

Thanks in advance...

Nancy Davis

Evidence of relaying: (In addition to having received this mail at "outside.domain.com")

secondary.outside.domain.com:~/bin> ./rlytest.pl -f user@secondary.outside.domain.com -u user%outside.domain.com
@host.our.edu -c "Testing mail relay off host" host.our.edu
Connecting to host.our.edu ...
<<< 220 host.our.edu ESMTP Exim 3.35 #1 Tue, 21 May 2002 22:40:37 -0600
>>> HELO secondary.outside.domain.com
<<< 250 host.our.edu Hello secondary.outside.domain.com [111.111.111.111]
>>> MAIL FROM:<user@secondary.outside.domain.com>
<<< 250 <user@secondary.outside.domain.com> is syntactically correct
>>> RCPT TO:<user%outside.domain.com@host.our.edu>
<<< 250 <user%outside.domain.com@host.our.edu> verified
>>> DATA
<<< 354 Enter message, ending with "." on a line by itself
>>> (message body)
<<< 250 OK id=17ANvR-0000Tq-00
>>> QUIT
<<< 221 host.our.edu closing connection
rlytest.pl: relay accepted - final response code 221

Configuration file:

qualify_domain = host.our.edu
local_domains = host.our.edu:localhost
local_domains_include_host = true
local_domains_include_host_literals = true
host_lookup = *
host_accept_relay = 127.0.0.1 : ::::1
host_auth_accept_relay = *
trusted_users = mail
smtp_verify = false
gecos_pattern = ^([^,:]*)
gecos_name = $1
smtp_accept_queue_per_connection = 100
freeze_tell_mailmaster = true
received_header_text = "Received: \
${if def:sender_rcvhost {from ${sender_rcvhost}\n\t}\
{${if def:sender_ident {from ${sender_ident} }}\
${if def:sender_helo_name {(helo=${sender_helo_name})\n\t}}}}\
by ${primary_hostname} \
${if def:received_protocol {with ${received_protocol}}} \
(Exim ${version_number} #${compile_number} (Debian))\n\t\
id ${message_id}\
${if def:received_for {\n\tfor <$received_for>}}"
receiver_try_verify = true
local_delivery:
driver = appendfile
group = mail
mode = 0660
mode_fail_narrower = false
envelope_to_add = true
return_path_add = true
file = /var/spool/mail/${local_part}
address_pipe:
driver = pipe
path = /usr/bin:/bin:/usr/local/bin
return_output
address_file:
driver = appendfile
envelope_to_add = true
return_path_add = true
address_directory:
driver = appendfile
no_from_hack
prefix = ""
suffix = ""
address_reply:
driver = autoreply
procmail_pipe:
driver = pipe
command = "/usr/bin/procmail"
return_path_add
delivery_date_add
envelope_to_add
suffix = ""
remote_smtp:
driver = smtp
real_local:
prefix = real-
driver = localuser
transport = local_delivery
system_aliases:
driver = aliasfile
file_transport = address_file
pipe_transport = address_pipe
file = /etc/aliases
search_type = lsearch
smart:
driver = smartuser
new_address = ${local_part}@our.edu
smarthost:
driver = domainlist
transport = remote_smtp
route_list = "* our.edu bydns_a"
* * F,2h,15m; G,16h,2h,1.5; F,4d,8h
*@host.our.edu ${1}@our.edu Ffr
*@localhost ${1}@our.edu Ffr
*@host.our.edu ${lookup{$1}lsearch{/etc/email-addresses}\
{$value}fail} frFs
Re: percent hack relaying help, please [ In reply to ]
On Tue, 21 May 2002, Nancy Davis wrote:

> Any help in finding out why this host is relaying would be greatly
> appreciated.

Sigh. This looks like "the usual misunderstanding".

> Evidence of relaying: (In addition to having received this mail at "outside.domain.com")
>
> secondary.outside.domain.com:~/bin> ./rlytest.pl -f user@secondary.outside.domain.com -u user%outside.domain.com
> @host.our.edu -c "Testing mail relay off host" host.our.edu
> Connecting to host.our.edu ...
> <<< 220 host.our.edu ESMTP Exim 3.35 #1 Tue, 21 May 2002 22:40:37 -0600
> >>> HELO secondary.outside.domain.com
> <<< 250 host.our.edu Hello secondary.outside.domain.com [111.111.111.111]
> >>> MAIL FROM:<user@secondary.outside.domain.com>
> <<< 250 <user@secondary.outside.domain.com> is syntactically correct
> >>> RCPT TO:<user%outside.domain.com@host.our.edu>
> <<< 250 <user%outside.domain.com@host.our.edu> verified
> >>> DATA
> <<< 354 Enter message, ending with "." on a line by itself
> >>> (message body)
> <<< 250 OK id=17ANvR-0000Tq-00
> >>> QUIT
> <<< 221 host.our.edu closing connection
> rlytest.pl: relay accepted - final response code 221

That is no evidence at all. It is evidence that your host accepts the
address user%outside.domain.com@host.our.edu. That's all. There is no
evidence that it actually relays the message to user%outside.domain.com.

Of course, maybe it does. But you can't tell from that evidence.


--
Philip Hazel University of Cambridge Computing Service,
ph10@cus.cam.ac.uk Cambridge, England. Phone: +44 1223 334714.
Re: percent hack relaying help, please [ In reply to ]
Nancy Davis wrote:

> Hi Exim folks,
>
> I have a default satellite configuration that is relaying via percent
> hack. A copy of the exim.conf file is attached (sanitized).
>
> Any help in finding out why this host is relaying would be greatly
> appreciated. Please CC: me on replies, as I am not (yet;-) subscribed
> to this list.

You can restrict the hosts by setting percent_hack_domains

--
Dimitry
Re: percent hack relaying help, please [ In reply to ]
Hi Philip,

> > Any help in finding out why this host is relaying would be greatly
> > appreciated.
>
> Sigh. This looks like "the usual misunderstanding".

This is the default behavior from a Debian installation using the
defined "satellite" configuration. I was very surprised that the
default behavior was to relay.

> > Evidence of relaying: (In addition to having received this mail at "outside.domain.com")

Note:----------------------^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

> That is no evidence at all. It is evidence that your host accepts the
> address user%outside.domain.com@host.our.edu. That's all. There is no
> evidence that it actually relays the message to user%outside.domain.com.

Yes. The mail was received at user@outside.domain.com as stated above.
I apologize if I could have made that more clear.

> Of course, maybe it does. But you can't tell from that evidence.

I was able to solve the problem on my own by permitting percent hack relaying
for my own domain - however, find this somewhat counter-intuitive. I also find the
dismissal of my request for help somewhat disheartening.

Nancy Davis
Re: percent hack relaying help, please [ In reply to ]
One of our mail baggers got blacklisted by orbs for relaying % hack
domains, despite having it turned off. You didn't include enough
information to tell if this is what happened to you, but I'll share the
story anyway.

ok, we had domain isp.com. MX records looked like this:

@ IN MX 0 primary.isp.com.
IN MX 5 secondary.isp.com.
IN MX 10 tertiary.isp.com.

secondary and tertiary are running exim (3.32 at the time) w/ percent hack
turned off. primary was (not anymore, thankfully) running smail. smail
was configured to do percent hack relaying, but only if you were allowed
to use it for relaying anyway. That is, you were only allowed to send to
user%remote.com@isp.com if you could already send use the server to send
to user@remote.com. Basically this was open to our customers, or, more
literally, anyone using an IP address from our /18.

This worked for 5 years w/ all the servers running smail because all smail
installations saw this as a remote domain and rejected it up front (or
accepted if it was from our IP block.

When we put exim on secondary and tertiary, this broke. exim on secondary
saw user%remote.com@isp.com purely as an address to be bagged for, with
the bizarre username of user%remote.com, and accepted it from the sender
no matter who the sender was. Then, secondary handed it to primary, and
this is where it broke. primary _did_ recognize it as a percent hack
domain, _and_ secondary was allowed to relay to remote recips, so the mail
got delivered to user@remote.com. I guess the point is, even when all the
pieces are working as expected, they may not interact the way you think
they will.

I solved all this by putting a router in place that rejects any email w/ a
% or a ! in the username (turns out after I fixed the % problem, smail
also had a problem w/ !, presumably because of it's uucp handling role).

</long explanation>

--John
Re: percent hack relaying help, please [ In reply to ]
On Wed, 22 May 2002, Nancy Davis wrote:

> > > Evidence of relaying: (In addition to having received this mail at "outside.domain.com")
>
> Note:----------------------^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

Oops. Apologies. My mistake. I didn't spot the parenthetical remark. My
only excuse is that I have to try really hard to minimize the time I
spend dealing with the Exim list, as otherwise I wouldn't get anything
else done. But I've done this too often lately. I must read more
carefully before posting.

Guess I need a vacation. That gives me an excuse to tell the list that I
will be away on vacation (and not reading email) next week.

> I was able to solve the problem on my own by permitting percent hack relaying
> for my own domain - however, find this somewhat counter-intuitive. I also find the
> dismissal of my request for help somewhat disheartening.

Apologies again. I did not intend at all to be dismissive.

I'm not familiar with the Debian configurations. What did you find
counter-intuitive? As far as vanilla Exim is concerned (as shipped by
me), it doesn't do percent-hack forwarding by default. If you want to
permit it, you have to tell it which of your domains it should do it
for. That seems logical to me, but maybe there's something I've missed?

Philip

--
Philip Hazel University of Cambridge Computing Service,
ph10@cus.cam.ac.uk Cambridge, England. Phone: +44 1223 334714.
Re: percent hack relaying help, please [ In reply to ]
In article <20020522125308.205FD6F5AC@betafo.cs.utah.edu>,
Nancy Davis <nedavis@cs.utah.edu> wrote:
>Hi Philip,
>
>> > Any help in finding out why this host is relaying would be greatly
>> > appreciated.
>>
>> Sigh. This looks like "the usual misunderstanding".
>
>This is the default behavior from a Debian installation using the
>defined "satellite" configuration. I was very surprised that the
>default behavior was to relay.

It probably doesn't relay, but it accepts the address, and sends
it to a smarthost unmodified. That smarthost relays for you, and
does use the % for routing. Result: 2-stage open relay.

Mike.
--
"Insanity -- a perfectly rational adjustment to an insane world."
- R.D. Lang
Re: percent hack relaying help, please [ In reply to ]
Philip,

> Guess I need a vacation. That gives me an excuse to tell the list that I
> will be away on vacation (and not reading email) next week.

Have a nice vacation.

> I'm not familiar with the Debian configurations. What did you find
> counter-intuitive? As far as vanilla Exim is concerned (as shipped by

The concept that I needed to permit percent hack relaying for a restricted
domain in order to turn it off for outside domains. It would seem that if
I left this unconfigured (as it was in the example sent), it should not
permit relaying. That was not the case. I have configured two hosts as
internet sites where the percent hack relay was not defined and they
behaved as I expected - they did not permit relaying. Default relaying
behavior only happened when I defined the hosts as satellite systems and
left the percent hack relay item undefined.

> me), it doesn't do percent-hack forwarding by default. If you want to
> permit it, you have to tell it which of your domains it should do it
> for. That seems logical to me, but maybe there's something I've missed?

I have forwarded the information to the person who is listed as maintaining
the Debian package for exim. I have not heard back from them.

Thanks for your assistance with this. Looks like I need to invest in yet
another O'Reilly book ;-)

Nancy
RE: percent hack relaying help, please [ In reply to ]
It may help to use a rewrite rule that modifies the to-Header:

*@target.system.org @relay.system.org:$local_part@$domain T

Then ignore the local system in the DNS Router
ignore_target_hosts = 0.0.0.0 : 127.0.0.0.0/8 : this.system.org


This should work without enabling the percent hack.

Ed...

-----Original Message-----
From: Nancy Davis [mailto:nedavis@cs.utah.edu]
Sent: Wednesday, May 22, 2002 11:07 AM
To: exim-users@exim.org
Subject: Re: [Exim] percent hack relaying help, please

Philip,

> Guess I need a vacation. That gives me an excuse to tell the list that
I
> will be away on vacation (and not reading email) next week.

Have a nice vacation.

> I'm not familiar with the Debian configurations. What did you find
> counter-intuitive? As far as vanilla Exim is concerned (as shipped by

The concept that I needed to permit percent hack relaying for a
restricted
domain in order to turn it off for outside domains. It would seem that
if
I left this unconfigured (as it was in the example sent), it should not
permit relaying. That was not the case. I have configured two hosts as
internet sites where the percent hack relay was not defined and they
behaved as I expected - they did not permit relaying. Default relaying
behavior only happened when I defined the hosts as satellite systems and
left the percent hack relay item undefined.

> me), it doesn't do percent-hack forwarding by default. If you want to
> permit it, you have to tell it which of your domains it should do it
> for. That seems logical to me, but maybe there's something I've
missed?

I have forwarded the information to the person who is listed as
maintaining
the Debian package for exim. I have not heard back from them.

Thanks for your assistance with this. Looks like I need to invest in
yet
another O'Reilly book ;-)

Nancy


--

## List details at http://www.exim.org/mailman/listinfo/exim-users Exim
details at http://www.exim.org/ ##
Re: percent hack relaying help, please [ In reply to ]
On Wed, 22 May 2002, Nancy Davis wrote:

> Thanks for your assistance with this. Looks like I need to invest in yet
> another O'Reilly book ;-)

Note that the current edition of the O'Reilly book is for Exim 3. I am
still working on revising it for Exim 4 (which has some significant
differences).

--
Philip Hazel University of Cambridge Computing Service,
ph10@cus.cam.ac.uk Cambridge, England. Phone: +44 1223 334714.