invalid Return-Path

I am having a problem with a customer that allows it's users
to maintain
their own computers(RealEstate office).  They use some kind
of software
given to them by their corporate office and it defaults to
putting an
invalid email address in the Return-Path field(emailcompany 
no period
after the ).  In addition they are pushing multiple (semicolon
separated) email addresses into the From field.

Is there a way to block those within Surgemail before they
are left
sitting around in the outbound queue because the destination
email
servers are sending back a 400 error code when they will
never accept
the message and should have given us a 500 series error
code?

Thanks,
Lyle

Lyle Giese wrote:
> I am having a problem with a customer that allows it's
users to maintain
> their own computers(RealEstate office).  They use some
kind of software
> given to them by their corporate office and it defaults
to putting an
> invalid email address in the Return-Path
field(emailcompany  no period
> after the ).  In addition they are pushing multiple
(semicolon
> separated) email addresses into the From field.
> 
> Is there a way to block those within Surgemail before
they are left
> sitting around in the outbound queue because the
destination email
> servers are sending back a 400 error code when they
will never accept
> the message and should have given us a 500 series error
code?
> 
> Thanks,
> Lyle

You could try some "mfilter.rul" rules like so:

if (isin("Return-Path","company>")) then
    call report("postmasterexample.com",
"message to postmaster")
    reject "Sorry - your email return-path is
malformed"
end if

This will catch any mail that has a return path containing
"company>". 
It will send the postmaster a report (delete that line if
you don't want 
the reports) and the sender will get an immediate bounce
when they try 
to send. Depending on their mail client, it may display the
"Sorry" message.

Mfilter rules are applied to ALL mail - both inbound and
outbound. At 
least that is what I understand and my experience seems to
support it. 
You need to be very sure that your conditionals only match
"offending" 
emails.

-- 
Neil Herber
Corporate info at http://www.eton.ca/