On Mon, 2004-01-05 at 15:04 +0000, T. Horsnell
(tsh),F46,2219,01223247239 wrote:
> All mail to/from our site is handled by our mail hub,
> which in turn is fed by a UCam upstream relay (smarthost).
> External SMTP traffic is only permitted between
> our hub and his upstream relay.
>
> How does this setup affect the ACL 'verify=sender' option?
It doesn't affect that, since that doesn't actually try to _connect_ to
the remote machine, and hence doesn't fall foul of the firewall. If you
want to reject invalid _users_ at remote domains though, you need
callouts (verify=sender/callout), and _that's_ not going to work through
the firewall.
> The docs say that the sender address is passed thro' the
> routers to determine its validity, but what happens
> here, since the routers are arranged to forward all
> offsite mail to the smarthost?
With callouts enabled, your system will attempt to callout to the
_smarthost_. The smarthost will probably appear to accept the callout
mail, and therefore you'll accept the incoming mail anyway.
You're not actually accepting mail from the outside world directly
though, are you? The best option would be for your public-facing MX host
(which _can_ talk to the outside world) to do the sender verification
for you (and also to do recipient verification with callouts so it's not
accepting mail for invalid users at your domain). That way, you're not
causing an undeliverable bounce when this happens, your site just
doesn't accept the mail from the spammer in the first place.
If you can't do this, you need to find some way of verifying the
addresses for yourself. You leave the relay with undeliverable bounces
but if they run without sender verification they obviously like it that
way :)
Your problem is that the smarthost doesn't do _recipient_ verification
callouts when you send mail to it; it just accepts the mail and then
potentially bounces it back to you afterwards. Furthermore, the admin
isn't likely to _enable_ recipient verification since the same smarthost
is used directly by MUAs, and MUAs tend to be bad at handling rejection
at SMTP time -- it's better to accept and bounce.
If your use of the smarthost was voluntary, it would be simple enough to
work around it as I do for the IPv4 setup on my dialup box:
outgoing:
driver = manualroute
route_data = smtp.demon.co.uk
transport = remote_smtp
no_verify
outgoing_verify:
driver = dnslookup
transport = remote_smtp
verify_only
That's not going to work in an environment where outgoing port 25 is
actually firewalled and your verify_only router _cannot_ connect,
though. The fix would be to find a smarthost which you can use and which
does recipient verification for you.
They're unlikely to enable this on the main outgoing smarthost for
reasons described above, but maybe they'd be amenable to requests for
another smarthost for use in this way which _does_ do recipient
verification callouts.
Maybe they would permit your machine to talk the the outside world
purely for verification, if you ask nicely and promise to use the
smarthost for actually _sending_ mail.
Alternatively, maybe there's already another machine within the firewall
which does have permission to talk to the outside world directly, which
does do recipient verification callouts, and which you could use as a
smarthost at least for the verify_only router.
Finally, and I mention this for technical completeness and because it
might be useful in other contexts rather than because I'd really
advocate it in _your_ case, you could talk to a smarthost in the outside
world by using SMTPS or deploying IPv6 (with 6to4 it's trivial) and
letting _it_ do recipient verification when you call out to it. Even if
you use this only for verification and never for actually sending mail,
I strongly suggest you discuss this with the UCS before contemplating
it. If it's interpreted as an attempt to bypass the firewall (which
technically it is) then they may be unhappy. This is not a pleasant
experience, take it from me :)
Btw, try this:
gecos_name = "$1"
gecos_pattern = "^([^,]*),"
--
dwmw2
