How to change envelope RCPT TO address before calling milter
Anatoly....@pnpi.spb.ru
I have sendmail 8.13 running and commercial antispam program integrated
with sendmail using milter API.
Antispam program checks for spam incoming mail message only if
envelope RCPT address looks like some...@mydomain.com. But often
envelope recipient address of incoming mail has the form:
some...@mail.mydomain.com. mail.mydomain.com is the name of my mail
server which sends and receives mails for my users.
How can I translate address some...@mail.mydomain.com to
some...@mydomain.com before calling antispam program ? What
variants exist ? Any hints ?
Thank you.
Anatoly Oreshkin.
Jose Marcio Martins da Cruz
> Hello,
>
> I have sendmail 8.13 running and commercial antispam program integrated
> with sendmail using milter API.
>
> How can I translate address some...@mail.mydomain.com to
> some...@mydomain.com before calling antispam program ? What
> variants exist ? Any hints ?
Your antispam program can't check messages for a set of domains (both
mydomain.com and mail.mydomain.com, and eventually all aliases for your
domain) ?
The good answer depends on how your antispam program selects the domain
part of the recipient address inside the milter.
But another good thing to do is to masquerade all your outgoing messages
as domain.com...
Anatoly....@pnpi.spb.ru
list which is composed by me.
To minimize the cost of Antispam program license (it depends on number
of addresses checked) I've been forced to make this list consisting of
addresses only like us...@mydomain.com.
I could of course to set up addresses like us...@mail.mydomain.com then
I would have to translate us...@mydomain.com to
us...@mail.mydomain.com.
Unfortunately I don't know how antispam program selects the domain part
of the recipient address in the milter. However any proposed variants
would be of help.
I'm now masquerading all outgoing messages with domain part
mydomain.com however often incoming messages to us...@mail.mydomain.com
are received. And this fact is out of my scope.
Per Hedeland
If all your outgoing e-mail has sender addresses of the form
us...@mydomain.com, and you don't otherwise suggest (on business cards or
whatever) that us...@mail.mydomain.com can be used, it's simply an
invalid address - why do you want to rewrite it and process it as
equivalent to us...@mydomain.com? Just reject it in the SMTP dialogue
with a "User unknown" or "Relaying denied" (can be done trivially with
Local_check_rcpt).
I don't remember if sendmail-rejected recipient addresses are passed to
the milter(s) (I think not, but someone will surely correct me if I'm
wrong on that), but in any case you don't have to worry about lack of
antispam scanning allowing for spam to be delivered to those recipients
- if the sendmail rules reject the recipient, it will be excluded from
delivery.
--Per Hedeland
p...@hedeland.org
Jose Marcio Martins da Cruz
At RCPT command, sendmail calls the milter ***before*** it checks if the
recipient is a valid address or not. So it pass it to the milter.
Per Hedeland
<mar...@paris.ensmp.fr> writes:
>Per Hedeland wrote:
>>
>> I don't remember if sendmail-rejected recipient addresses are passed to
>> the milter(s) (I think not, but someone will surely correct me if I'm
>> wrong on that), but in any case you don't have to worry about lack of
>> antispam scanning allowing for spam to be delivered to those recipients
>> - if the sendmail rules reject the recipient, it will be excluded from
>> delivery.
>
>At RCPT command, sendmail calls the milter ***before*** it checks if the
>recipient is a valid address or not. So it pass it to the milter.
OK - but delivery to that recipient still shouldn't happen - unless you
have an extremely weird milter, that tells sendmail to delete all
recipients, and then does the delivery itself...
--Per Hedeland
p...@hedeland.org
Anatoly....@pnpi.spb.ru
server mail.mydomain.com and users had both us...@mail.mydomain.com
address and us...@mydomain.com. So they received mail to both
addresses. Some of them subscribed to various mailing lists with
either first or second form of address. Thefore to transit to one form
of address as painless as possible I would like to translate from
us...@mail.mydomain.com to us...@mydomain.com or vice verse.
You have proposed to reject mail in ruleset Local_check_rcpt. As I
understand such rule would look like this ?:
R$+@mail.mydomain.com $#error $@ nouser $: "Sorry, use address like
us...@mydomain.com"
This approach could be suitable if a sender is a human and having
received the error message he/she would resend a mail to right address.
But in case of the sender being robot this method is hardly
appropriate.
Are there other methods ? For example to have 2 instances of
sendmail on the same server.
One sendmail instance without milter antispam on receiving mail resends
the mail to another sendmail instance (with milter antispam) on the
same server but to address us...@mydomain.com. The file virtusertable
would contain such a line
@mail.mydomain.com %1...@mydomain.com
Although this metod is ugly but would it work ?
May be there is another way.
Taylor, Grant
> sendmail on the same server.
I don't know if it would accomplish what you are wanting or not, but what would happen if you added "domain.tld" and "mail.domain.tld" to your local-host-name file (Sendmail "Fw<file>"?
Grant. . . .
Per Hedeland
"Anatoly....@pnpi.spb.ru" <Anatoly....@pnpi.spb.ru> writes:
>Before installing antispam program there was no masqerading on our
>server mail.mydomain.com and users had both us...@mail.mydomain.com
>address and us...@mydomain.com. So they received mail to both
>addresses. Some of them subscribed to various mailing lists with
>either first or second form of address. Thefore to transit to one form
>of address as painless as possible I would like to translate from
>us...@mail.mydomain.com to us...@mydomain.com or vice verse.
OK, I see - too bad.:-)
>You have proposed to reject mail in ruleset Local_check_rcpt. As I
>understand such rule would look like this ?:
>
>R$+@mail.mydomain.com $#error $@ nouser $: "Sorry, use address like
>us...@mydomain.com"
More or less - you probably need R<$+@mail.mydomain.com> in the LHS, or
better send it through ruleset 3 first to get it into "canonical form":
R$+ $: $>3 $1
R$+<@mail.mydomain.com.> $#error ...
Actually it doesn't have to be custom rules in Local_check_rcpt, any
recipient processing will do - you could e.g. use FEATURE(redirect) and
put this in virtusertable to get a nice message for all users:
@mail.mydomain.com %1...@mydomain.com.REDIRECT
>This approach could be suitable if a sender is a human and having
>received the error message he/she would resend a mail to right address.
>But in case of the sender being robot this method is hardly
>appropriate.
Well, the 551 response produced by FEATURE(redirect) is supposedly
machine-parseable, but I don't know of any machines that parse it. And
absent that, assuming that any SMTP response is a) reported back to the
sender and b) actually read and understood by the sender, is probably
optimistic. But they can generally realize "it didn't work".
>Are there other methods ? For example to have 2 instances of
>sendmail on the same server.
>One sendmail instance without milter antispam on receiving mail resends
>the mail to another sendmail instance (with milter antispam) on the
>same server but to address us...@mydomain.com. The file virtusertable
>would contain such a line
>
>@mail.mydomain.com %1...@mydomain.com
>
>Although this metod is ugly but would it work ?
Yes it is ugly, and yes it should work. Assuming that you can really get
the different addresses routed to the right instance, which would likely
require running the instances on separate IP addresses and being
"creative" with the MX records - extra ugly.:-)
>May be there is another way.
In your particular situation, I'm not sure there is one that is better.
You could conceivably do it all in one sendmail instance, and have it
send the rewritten recipient back to "itself", if instead of
virtusertable you used someing like:
MODIFY_MAILER_FLAGS(`SMTP', `+k')
LOCAL_RULE_0
R$+<@mail.mydomain.com.> $#smtp $@ [127.0.0.1] $: $1<@mydomain.com.>
It would get sent to the milter in both rounds of course - but the
milter getting the us...@mail.mydomain.com addresses in the first round
shouldn't be a problem, since they will not cause scanning. The bad case
would be if you had a mixture of us...@mydomain.com and
us...@mail.mydomain.com recipients for a single message, which would
cause the message to be scanned twice (in the first round for the
"original" us...@mydomain.com, in the second round for the
us...@mail.mydomain.com rewritten to us...@mydomain.com). But maybe this
would be very unusual.
--Per Hedeland
p...@hedeland.org
Anatoly....@pnpi.spb.ru
works !
The only change I've made is that I've replaced 127.0.0.1 for
127.0.0.2 because antispam skips mail from localhost (127.0.0.1)
Only drawback of this method is that a mail passes twice through
sendmail, antispam and antivirus. Antivirus program is also
integrated with sendmail using milter API.
First time a mail passes antispam it is not checked for spam and second
time when domain part of address being changed to mydomain.com it is
checked for spam.
It looks like there is no better choice as I think.
Any way this approach solves my problem.
Thank you very much for help !
Per Hedeland
"Anatoly....@pnpi.spb.ru" <Anatoly....@pnpi.spb.ru> writes:
>I've chosen second variant, the one with one sendmail instance. And it
>works !
>The only change I've made is that I've replaced 127.0.0.1 for
>127.0.0.2 because antispam skips mail from localhost (127.0.0.1)
You could alternatively use the IP address of the physical interface, or
even the host name inside [brackets] (to avoid MX lookup).
>Only drawback of this method is that a mail passes twice through
>sendmail, antispam and antivirus. Antivirus program is also
>integrated with sendmail using milter API.
>First time a mail passes antispam it is not checked for spam and second
>time when domain part of address being changed to mydomain.com it is
>checked for spam.
Actually there's another drawback with both this and the two-instance
scheme, that occurred to me after posting: If your milter(s) reject mail
during the SMTP session (which they should if they reject at all), this
will nicely lay the burden of any bounces on the sender, and avoid bogus
bounces from you to "innocent" faked senders (see many discussions here
and elsewhere). However this will only work right for the "first round"
- with rejection after rewrite+forward to the "second round", your own
sendmail is the sender, and can only choose between the two evils of
sending a bounce (will happen by default) or dropping the whole thing.
If I were in your situation, I would probably consider this drawback
serious enough to warrant modifying the sendmail source code to achieve
the goal of having the milter(s) do all scanning in the "first round".
(And once there, I would be quite tempted to make use of a pretty
obvious way to circumvent the milter licensing scheme that forced me to
go to this trouble, and only actually pay for a single user/address...
- but I think I'll stop here.:-)
--Per Hedeland
p...@hedeland.org
Joseph Brennan
"Anatoly....@pnpi.spb.ru" <Anatoly....@pnpi.spb.ru> writes:
>Antispam program checks messages with addresses from the addresses'
>list which is composed by me.
>To minimize the cost of Antispam program license (it depends on number
>of addresses checked) I've been forced to make this list consisting of
>addresses only like us...@mydomain.com.
>I could of course to set up addresses like us...@mail.mydomain.com then
>I would have to translate us...@mydomain.com to
>us...@mail.mydomain.com.
If us...@mydomain.com and us...@mail.mydomain.com are equivalent, are
you totally sure the antispam vendor will charge for them as two
addresses? I've never heard of that before.
Joseph Brennan
jma...@ttec.com
use the milter-rrres patch, it will do exactly thay.
http://www.jmaimon.com/sendmail
All you then need to do is write a ruleset that acheives your
objectives.
> Thank you.
> Anatoly Oreshkin.
jma...@ttec.com
milter-rrres patch addresses this as well
Anatoly....@pnpi.spb.ru
> In article <1146897645.3...@i39g2000cwa.googlegroups.com>
> "Anatoly....@pnpi.spb.ru" <Anatoly....@pnpi.spb.ru> writes:
> >I've chosen second variant, the one with one sendmail instance. And it
> >works !
> >The only change I've made is that I've replaced 127.0.0.1 for
> >127.0.0.2 because antispam skips mail from localhost (127.0.0.1)
>
> You could alternatively use the IP address of the physical interface, or
> even the host name inside [brackets] (to avoid MX lookup).
>
> >Only drawback of this method is that a mail passes twice through
> >sendmail, antispam and antivirus. Antivirus program is also
> >integrated with sendmail using milter API.
> >First time a mail passes antispam it is not checked for spam and second
> >time when domain part of address being changed to mydomain.com it is
> >checked for spam.
>
> Actually there's another drawback with both this and the two-instance
> scheme, that occurred to me after posting: If your milter(s) reject mail
> during the SMTP session (which they should if they reject at all), this
> will nicely lay the burden of any bounces on the sender, and avoid bogus
> bounces from you to "innocent" faked senders (see many discussions here
> and elsewhere). However this will only work right for the "first round"
> - with rejection after rewrite+forward to the "second round", your own
> sendmail is the sender, and can only choose between the two evils of
> sending a bounce (will happen by default) or dropping the whole thing.
Milter antispam does not make any decision relating what to do with
mail.
It only just adds
X-Spam-Flag: YES/NO/SKIP
to header depending on various conditions
and that's all.
The final delivery is accomplished by procmail by analyzing
X-Spam-Flag
after processing mail by milter antispam.
Procmailrc is set up by me for every user and may be customized on
user's demand.
>
> If I were in your situation, I would probably consider this drawback
> serious enough to warrant modifying the sendmail source code to achieve
> the goal of having the milter(s) do all scanning in the "first round".
> (And once there, I would be quite tempted to make use of a pretty
> obvious way to circumvent the milter licensing scheme that forced me to
> go to this trouble, and only actually pay for a single user/address...
> - but I think I'll stop here.:-)
I have neither time nor enough experience to modify sendmail source.
Probably in next sendmail releases there will be such possibility.
>
> --Per Hedeland
> p...@hedeland.org
jma...@ttec.com
Anatoly....@pnpi.spb.ru wrote:
> Per Hedeland wrote:
>
> I have neither time nor enough experience to modify sendmail source.
> Probably in next sendmail releases there will be such possibility.
>
Just curious -- have you tried the patch?
>
> >
> > --Per Hedeland
> > p...@hedeland.org