Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

Sending email with a specific domain

25 views
Skip to first unread message

steve76

unread,
Feb 21, 2018, 4:02:15 AM2/21/18
to
Hi,

I am using Sendmail with for multi-domains

domainA.com and domainB.com

Clients are conecting ( like Thunderbird ) to this server..
each user manage it's thunderbird client and I wish to avoid sending
email as :

us...@domainC.com

Beacause of multi domain, I don't want to use the Masquarade, whih I
think is to rewrite the domain name on the email. In my case, this make
no sens. But I would like the system to STOP any emails or NOT TO ACCEPT
any emails as ..@domainC.com (which doesn't belong to us ..

how to do this ? via Sendmail ? should we use Procmail for that ??
Actually, I have no idea

steve76

unread,
Feb 22, 2018, 5:22:05 AM2/22/18
to
I had a look and MASQUERADE_AS is changing the domain of the meail sent...
I don't want to change it. I just want to stop emails, with domain names
NOT into local domain...
Any idea ?

steve76

unread,
Feb 22, 2018, 6:04:51 AM2/22/18
to
FYI, I've just tested

and added
Feature FEATURE(generics_entire_domain)dnl
Other GENERICS_DOMAIN(`domainA.com')

And I can send with the user b...@domainb.com !!!
It sholdn't !

Claus Aßmann

unread,
Feb 22, 2018, 7:18:32 AM2/22/18
to
steve76 wrote:

> I am using Sendmail with for multi-domains

> domainA.com and domainB.com

> Clients are conecting ( like Thunderbird ) to this server..
> each user manage it's thunderbird client and I wish to avoid sending
> email as :

> us...@domainC.com

Why?
You probably want to receive mail from us...@domainC.com, right?
How do you determine which client can use which address?

Do you want to implement this only for authenticated users (AUTH)?
Then check the supplied identity (e.g., ${auth_*} macros)
and match it against the MAIL address ($f) in Local_check_mail.

Someone might have already written rules for that, so maybe
try a search.

--
Note: please read the netiquette before posting. I will almost never
reply to top-postings which include a full copy of the previous
article(s) at the end because it's annoying, shows that the poster
is too lazy to trim his article, and it's wasting the time of all readers.

steve76

unread,
Feb 22, 2018, 7:44:45 AM2/22/18
to
On 02/22/2018 01:18 PM, Claus Aßmann wrote:
> steve76 wrote:
>
>> I am using Sendmail with for multi-domains
>
>> domainA.com and domainB.com
>
>> Clients are conecting ( like Thunderbird ) to this server..
>> each user manage it's thunderbird client and I wish to avoid sending
>> email as :
>
>> us...@domainC.com
>
> Why?
> You probably want to receive mail from us...@domainC.com, right?
> How do you determine which client can use which address?
>
> Do you want to implement this only for authenticated users (AUTH)?
> Then check the supplied identity (e.g., ${auth_*} macros)
> and match it against the MAIL address ($f) in Local_check_mail.
>
> Someone might have already written rules for that, so maybe
> try a search.
>

no no.. What I would like to do, is to avoid "create" SPAM emails..

this is not on INCOMING Emails, but for OUTGOING Emails...

Let suppose that you have a company with a couple of employes, and one
of them decide to use email sender address as : FROM ...x...@gmail.com

of course, you are not necessary aware and my fear is that after a
while, our IP address will be detected as SPAM, because some GMAIL
Address are going out from our server...

I would like to find a way to avoid this.
Sendmail is managing some local domain name "domain1.com" and
"domain2.com".. and it needs to check that outgoing domain name ( on out
going emails ) are the one that it manage..

Claus Aßmann

unread,
Feb 22, 2018, 8:54:26 AM2/22/18
to
steve76 wrote:

> this is not on INCOMING Emails, but for OUTGOING Emails...

Every mail must come in before going out...
Hence you check at the INCOMING side.

steve76

unread,
Feb 22, 2018, 9:51:27 AM2/22/18
to
??????????
You know, I am using thunderbird..
I have a section called "settings" -> "manage Identities"
Into this, I can create a new identities and says..
user1 ; us...@gmail.com

and My email address display, when I want to send an email will be :
from us...@gmail.com.. with no problem, sendmail will let me send this
email.. and that's the problem
On the other side, the header of the email will says..

sender xxx@gmail .. IP address.. ( out IP addres ) "May be forged" ! )
etc.......
Which is not godd for IP reputation

Grant Taylor

unread,
Feb 24, 2018, 11:40:25 PM2/24/18
to
On 02/22/2018 07:51 AM, steve76 wrote:
> ??????????

Claus is saying that when you send an email from Thunderbird, that the
mail server is receiving it, processing it for relay, and subsequently
sending it out to the world. The first stage, where Sendmail receives
the message from Thunderbird is where Claus is talking about filtering
the purported sender (RFC 821 MAIL FROM:<…> and / or RFC 822 From:
header). I.e. authenticated user A is allowed to send emails from
A...@domain1.example and A...@domain2.example but not anything else.

> You know, I am using thunderbird..
> I have a section called "settings" -> "manage Identities"
> Into this, I can create a new identities and says..
> user1 ; us...@gmail.com

Yes, SMTP in general will allow you to specify what ever you want in the
RFC 821 MAIL FROM and the RFC 822 From: header. - This in and of
itself is a source of a lot of trouble.

> and My email address display, when I want to send an email will be :
> from us...@gmail.com.. with no problem, sendmail will let me send this
> email.. and that's the problem

Sendmail, and most MTAs that I've tested, will let you send exactly what
you're describing.

Just because Sendmail will allow you to send it does NOT mean that the
emails will get through. There are a number of things looking for,
detecting, and reporting / blocking this very behavior.

- SPF
- DKIM
- DMARC

> On the other side, the header of the email will says..
>
> sender xxx@gmail .. IP address.. ( out IP addres )  "May be forged" ! )
> etc.......

I'm used to the "May be forged" being related to forward and reverse
DNS, particularly in conjunction with the EHLO name that you use. At
least I'm not aware of bad smtp envelope from addresses ever causing
"May be forged" messages.

> Which is not godd for IP reputation

I agree in theory. But I've never needed to worry about that in the
time that I've been administering email servers.

I think it's more important to authenticate the client that's connecting
to the server, via SMTP Authentication (or possibly via SSL
certificate?) and then smack their hands if (when) they do something
they should not be doing. After all, you have authenticated which user
account is being used to send the messages.

Things happen. Mistakes get made. Own up to them and fix them. Most
good admins that I've ever dealt with will cut you some slack if you
show that you're trying to do the correct thing.

Finally, run some standard hygiene on outgoing email and you will likely
be okay.



--
Grant. . . .
unix || die

steve76

unread,
Feb 27, 2018, 3:38:22 AM2/27/18
to
So fo you, the best is to manage unwanted "email" with the SPF ( to
reject it... ) and there is no risk to consider the public IP address
as SPAM ? which would be a disaster for everybody ...


Grant Taylor

unread,
Feb 27, 2018, 10:17:28 PM2/27/18
to
On 02/27/2018 01:38 AM, steve76 wrote:
> So fo you, the best is to manage unwanted "email"  with the SPF ( to
> reject  it... ) and there is no risk to consider the public IP address
> as SPAM ? which would be a disaster for everybody ...

I personally believe that if a sending domain says that they will only
send email from specific locations, and email comes from somewhere else,
then 1) it's either not from them or 2) they have a problem and the onus
is on them to fix their SPF record.

Reputation is supposedly a thing. I've not personally run into it on my
small time mail servers that I've run.

Everybody that I know, myself included, that has run a mail server has
had a problem, be it an accidental open relay, or an infected client
that's authorized, or DNS issues. Mistakes happen. It's how you
respond that matters. If you get black listed, you appeal to the black
list and ask to be removed. I think I've had something get listed two
or three times in 18+ years.

People usually do want email to flow. Thus they want things to not
block it. People will usually tell you why they don't want your email
(if / when they don't), especially if you're polite and ask what you
need to fix.

At least that's been my experience.
0 new messages