masquerade as anything specified in "From:" line
am 23.12.2007 14:26:55 von trbosjek
Hello,
New to sendmail. I have been able to use MASQUERADE_AS to make the
messages appear to the recipient as sent from a domain name that I
have chosen. But, my requirement goes beyond this. Let us assume that
the mail is sent with this command:
sendmail -t <///
To: email@address
From: whateverIwant
////
As long as I enter something@somewhere in "From:" line, I get what is
in the "From" line. But, when I omit the "@" sign and what is behind
it, I get what is specified in MASQUERADE_AS. And if the "something"
is root, then I get the FQDN instead of what is in MASQUERADE_AS . I
want the recipient to see exactly what is typed in the "From" line. No
more, no less. The only thing that I can accept is if the "From" line
is missing, then sendmail can put whatever it wants. But "nothing"
would be the best option. How do I achieve this?
Re: masquerade as anything specified in "From:" line
am 23.12.2007 21:41:30 von per
In article
<60088765-785d-4e59-8418-ab93414b09e2@x29g2000prg.googlegroups.com>
trbosjek writes:
>
>New to sendmail. I have been able to use MASQUERADE_AS to make the
>messages appear to the recipient as sent from a domain name that I
>have chosen. But, my requirement goes beyond this. Let us assume that
>the mail is sent with this command:
>
>sendmail -t <///
>To: email@address
>From: whateverIwant
>////
>
>As long as I enter something@somewhere in "From:" line, I get what is
>in the "From" line. But, when I omit the "@" sign and what is behind
>it, I get what is specified in MASQUERADE_AS. And if the "something"
>is root, then I get the FQDN instead of what is in MASQUERADE_AS . I
>want the recipient to see exactly what is typed in the "From" line. No
>more, no less. The only thing that I can accept is if the "From" line
>is missing, then sendmail can put whatever it wants. But "nothing"
>would be the best option. How do I achieve this?
Sendmail, for better or worse, doesn't easily allow you to send out
garbage. The RFCs require that the From: header has a fully-qualified
address, thus if whatever you put there doesn't have an '@', sendmail
will assume that it's dealing with a broken/stupid MUA that doesn't know
what a proper e-mail address looks like, and append
@ (the difference with root is just because you
use the EXPOSED_USERS() macro with `root').
Of course, sendmail being infinitely configurable, this behaviour isn't
hardwired in the program but is a result of the standard rules in
sendmail.cf. If you don't like it, you are free to replace some of those
rules with your own, which in this case as I mentioned isn't easy, but
certainly doable. Don't expect anyone else to spend the effort of
researching and telling you how to send out non-RFC-compliant mail,
though.
--Per Hedeland
per@hedeland.org
Re: masquerade as anything specified in "From:" line
am 26.12.2007 13:46:34 von trbosjek
"Don't expect anyone else to spend the effort of..."
I don't expect that. Have read a lot last couple of days. Now I know
what is LHS and RHS and how to make a rule do what I want. But, the
rules are used multiple times (I see that with -d21.12 switch). And
not for only one "type" of address. Those apply to both sender and
recipient address. So, when I change a rule to suit my needs for
sender address, it also changes the recipient address. How do I deal
with that?
Re: masquerade as anything specified in "From:" line
am 28.12.2007 23:47:50 von per
In article
trbosjek writes:
>"Don't expect anyone else to spend the effort of..."
>
>I don't expect that. Have read a lot last couple of days. Now I know
>what is LHS and RHS and how to make a rule do what I want. But, the
>rules are used multiple times (I see that with -d21.12 switch). And
>not for only one "type" of address. Those apply to both sender and
>recipient address. So, when I change a rule to suit my needs for
>sender address, it also changes the recipient address. How do I deal
>with that?
You read more (and test a lot). Making a rule is the trivial part, now
you need to figure out where it should go (or alternatively make more
rules that restrict the application of your original rule).
--Per Hedeland
per@hedeland.org