sendmail can't set subdomain

I

integrator

I can not set subdomain name for sendmail. As a result I can't receive external e-mails for that domain.
I spent much time there but did not find a solution.
 
here is my .mc

Code: 
divert(0)
VERSIONID(`$FreeBSD: release/9.0.0/etc/sendmail/freebsd.mc 223068 2011-06-14 04:33:43Z gshapiro $')
OSTYPE(freebsd6)
DOMAIN(generic)
LOCAL_DOMAIN(`autolobaz.by')dnl

FEATURE(access_db, `hash -o -T<TMPF> /etc/mail/access')
FEATURE(blacklist_recipients)
FEATURE(local_lmtp)
FEATURE(mailertable, `hash -o /etc/mail/mailertable')
FEATURE(virtusertable, `hash -o /etc/mail/virtusertable')
FEATURE(domaintable)dnl
FEATURE(`relay_entire_domain')
dnl Uncomment to allow relaying based on your MX records.
dnl NOTE: This can allow sites to use your server as a backup MX without
dnl       your permission.
dnl FEATURE(relay_based_on_MX)

dnl DNS based black hole lists
dnl --------------------------------
dnl DNS based black hole lists come and go on a regular basis
dnl so this file will not serve as a database of the available servers.
dnl For that, visit
dnl [url]http://www.google.com/Top/Computers/Internet/E-mail/Spam/Blacklists/[/url]

dnl Uncomment to activate your chosen DNS based blacklist
dnl FEATURE(dnsbl, `dnsbl.example.com')
dnl Alternatively, you can provide your own server and rejection message:
dnl FEATURE(dnsbl, `dnsbl.example.com', ``"550 Mail from " $&{client_addr} " rejected'')
GENERICS_DOMAIN_FILE(`/etc/mail/generics-domains')dnl
dnl Dialup users should uncomment and define this appropriately
dnl define(`SMART_HOST', `your.isp.mail.server')

dnl Uncomment the first line to change the location of the default
dnl /etc/mail/local-host-names and comment out the second line.
dnl define(`confCW_FILE', `-o /etc/mail/sendmail.cw')
define(`confCW_FILE', `-o /etc/mail/local-host-names')

dnl Enable for both IPv4 and IPv6 (optional)
DAEMON_OPTIONS(`Name=IPv4, Family=inet')
DAEMON_OPTIONS(`Name=IPv6, Family=inet6, Modifiers=O')
DAEMON_OPTIONS(`Port=smtp,Addr=178.172.148.149, Name=MTA')

define(`confDOMAIN_NAME', `mail.autolobaz.by')
define(`confBIND_OPTS', `WorkAroundBrokenAAAA')
define(`confNO_RCPT_ACTION', `add-to-undisclosed')
define(`confPRIVACY_FLAGS', `authwarnings,noexpn,novrfy')
define(`confHELO_NAME', `autolobaz.by')dnl


MASQUERADE_AS(`autolobaz.by')dnl 
FEATURE(masquerade_envelope)dnl
MAILER(local)
MAILER(smtp)
 
Just add autolobaz.by to /etc/mail/local-host-names. Can't remember if you have to restart Sendmail but may as well just to make sure. If you have any other domains you want to accept mail for, add them to the same file, one per line.

You shouldn't need to make any changes to the default mc/cf file at all for this to work.

If you still have problems, run the following and post the output. This is one of my most useful tools when configuring/testing Sendmail:

Code: 
# sendmail -bv user@autolobaz.by

Also, I can't tell what you've done from your posts (so you may be doing it right) but just for completeness, the correct method for editing the mc/cf file is as follows:

Code: 
# cd /etc/mail
# make
# *** edit the file called {hostname}.mc ***
# make install restart

(Obviously the first make only needs to be done the first time and does the initial setup - such as creating the {hostname}.mc, {hostname}.submit.mc files)

Additionally, if you want to accept mail for other addresses that don't map directly to a user (like info@mydomain.com), add the address to /etc/mail/virtusertable, followed by a space or tab, then the local user (or another external email address) to deliver the mail to. Run the 'make install restart' command above to install the new virtusertable and restart Sendmail.
 
I am use Webmin for configuration. For external mails I get
Code: 
550 550 relay not permitted (state 13)
I did make install many times. Below are requested outputs:
Code: 
ximena# cat /etc/mail/local-host-names 
autolobaz.by
ximena# cat /etc/mail/virtusertable
# $FreeBSD: release/9.0.0/etc/mail/virtusertable.sample 68266 2000-11-02 23:32:31Z dirk $
#
# Map one or all usernames at a source hostname to a specific (or the same)
# username at another target hostname.  Remember to add the source hostname
# to /etc/mail/local-host-names so that sendmail will accept mail for the
# source hostname.
#
[email]autolobaz@autolobaz.by[/email]	localuser
[email]autolobaz@autolobaz.by[/email]	[email]autolobaz@ximena.neolocation.net[/email]
@mail.autolobaz.by	[email]autolobaz@ximena.neolocation.net[/email]
@yet.mail.autolobaz.by	%1@ximena.neolocation.net
ximena# sendmail -bv [email]autolobaz@autolobaz.by[/email]
[email]autolobaz@autolobaz.by[/email]... deliverable: mailer local, user autolobaz
ximena#
 
You're seem to be starting to confuse me now.
I'm assuming that your local hostname is ximena.neolocation.net and you have a local user called 'autolobaz'. You also want to accept mail for 'autolobaz.by'.

Your /etc/mail/local-host-names looks fine. The server will accept mail for its hostname by default and should also accept for any domain in this file so that's all good.

The /etc/mail/virtusertable is a bit of a mess. I doubt it will convert into the required database format correctly as you have [email='autolobaz@autolobaz.by]'autolobaz@autolobaz.by[/email]' specified twice. (Sendmail actually uses /etc/mail/virtusertable.db)

Code: 
autolobaz@autolobaz.by	localuser

This line doesn't make sense unless you actually have a user account on the machine called 'localuser'. If your local user is called 'autolobaz', you don't need this as any email to {valid local user}@{accepted local domain name} gets delivered to {valid local user} anyway.

Code: 
autolobaz@autolobaz.by	autolobaz@ximena.neolocation.net

This line duplicates the address from the first line and as mentioned will probably stop the virtusertable database from building. Again if your user account is called autolobaz, you don't need this. Your server is set to accept email for 'autolobaz.by' and so without any entry in virtusertable, autolobaz@autolobaz.by will be delivered to user autolobaz.

The third line looks ok but the last line doesn't appear to be required. Also, to accept mail for the domains mail.autolobaz.by and yet.mail.autolobaz.by, these will need to be in /etc/mail/local-host-names

On one of my FreeBSD 9.0 machines I've just discovered that 'make install' doesn't actually rebuild the virtusertable for me. I had to just run 'make'. You should see it run a makemap commend to build the virtusertable database. (makemap hash virtusertable < virtusertable)

Regardless, this line below shows that Sendmail should be accepting mail for autolobaz@autolobaz.by, and delivering it to local user 'autolobaz'.

Code: 
ximena# sendmail -bv autolobaz@autolobaz.by
autolobaz@autolobaz.by... deliverable: mailer local, user autolobaz

I don't think your virtusertable is working at all but as you have listed autolobaz.by as an accepted domain in /etc/mail/local-host-names, it is accepting the mail and delivering to user autolobaz.

If you are still getting relaying denied when trying to deliver external mail to this address, please post the relevant lines from /var/log/maillog. Your error doesn't make much sense as the 'sendmail -bv' command confirms that the server should be delivering email locally for that address and not relaying, unless you haven't actually restarted the running Sendmail daemon...
 
Thank you for your detailed explanation. But I still faced with the same problem. I has try to leave a one or two lines in /etc/mail/virtusertable (you can see output below). I also has try to execute just "make" with reboot and external restart via Webmin.
Code: 
@mail.autolobaz.by      [email]autolobaz@ximena.neolocation.net[/email]
@autolobaz.by      [email]autolobaz@ximena.neolocation.net[/email]
"/etc/mail/virtusertable" 10 lines, 444 characters
ximena# make
/usr/sbin/makemap hash virtusertable.db < virtusertable
chmod 0640 virtusertable.db
ximena# make install restart
install -m 444 ximena.cf /etc/mail/sendmail.cf
install -m 444 ximena.submit.cf /etc/mail/submit.cf
Restarting: sendmail sendmail-clientmqueue.
ximena#
I was surprised that there is no activity for autolobaz@autolobaz.by in /var/log/maillog. But for autolobaz@ximena.neolocation.net I can see such activity.
Code: 
Oct 31 10:34:37 ximena sendmail[88992]: restarting /usr/sbin/sendmail due to signal
Oct 31 10:34:37 ximena sendmail[89020]: starting daemon (8.14.5): SMTP+queueing@00:30:00
Oct 31 10:34:37 ximena sm-msp-queue[1465]: restarting /usr/sbin/sendmail due to signal
Oct 31 10:34:37 ximena sm-msp-queue[89024]: starting daemon (8.14.5): queueing@00:30:00
Oct 31 10:40:04 ximena sendmail[89020]: restarting /usr/sbin/sendmail due to signal
Oct 31 10:40:04 ximena sm-msp-queue[89024]: restarting /usr/sbin/sendmail due to signal
Oct 31 10:40:04 ximena sendmail[89106]: starting daemon (8.14.5): SMTP+queueing@00:30:00
Oct 31 10:40:04 ximena sm-msp-queue[89107]: starting daemon (8.14.5): queueing@00:30:00
Oct 31 10:45:48 ximena sendmail[89160]: q9V7jlpu089160: from=<integrator@tut.by>, size=1642, class=0, nrcpts=1, msgid=<CAGzOMXY2WOq=PN56z1Dzx_19katk5EEhx3S96aVhNLicdZho=w@mail.gmail.com>, proto=ESMTP, daemon=IPv4, relay=mail-qa0-f50.google.com [209.85.216.50]
Oct 31 10:45:48 ximena sendmail[89161]: q9V7jlpu089160: to=<autolobaz@ximena.neolocation.net>, delay=00:00:00, xdelay=00:00:00, mailer=local, pri=31919, relay=local, dsn=2.0.0, stat=Sent
ximena#
 
Still having the problem?

There is no relaying error in your log. The below log messages report a message coming in from mail-qa0-f50.google.com, successfully delivered to a local user. If the message isn't in your local mailbox then you've got other local delivery problems.

Code: 
Oct 31 10:45:48 ximena sendmail[89160]: q9V7jlpu089160: from=<integrator@tut.by>, size=1642, class=0, 
   nrcpts=1, msgid=<CAGzOMXY2WOq=PN56z1Dzx_19katk5EEhx3S96aVhNL icdZho=w@mail.gmail.com>, proto=ESMTP, 
   daemon=IPv4, relay=mail-qa0-f50.google.com [209.85.216.50]
Oct 31 10:45:48 ximena sendmail[89161]: q9V7jlpu089160: to=<autolobaz@ximena.neolocation.net>, delay=00:00:00, 
   xdelay=00:00:00, mailer=local, pri=31919, relay=local, dsn=2.0.0, stat=Sent

The reason you don't see autolobaz@autolobaz.by in the log is because sendmail has already resolved that to autolobaz@ximena.neolocation.net due to your virtusertable entries.

For example, if you had the below in your virtusertable, you'd just see 2 lines in your mail log. One for the message coming in, and the other for it going out to [email='me@mydomain.com]'me@mydomain.com[/email]'

Code: 
@autolobaz.by    me@mydomain.com

Also you could reduce your config files to the following (still assuming autolobaz is the name of your local user account):

/etc/mail/local-host-names
Code: 
autolobaz.by
mail.autolobaz.by
(accept mail for these 2 domains in addition to @{hostname})

/etc/mail/virtusertable
Code: 
@mail.autolobaz.by     autolobaz
@autolobaz.by          autolobaz
(forward any mail to *@mail.autolobaz.by & *@autolobaz.by to local user autolobaz)
 
Sorry but I still have a problem. I made a files exactly as you suggest. But no one mail from external mailbox to autolobaz@autolobaz.by was not delivered. There is no activity in /var/log/maillog for that period. I think I get my head off with that problem. The output below will help you to suggest me something maybe?
Code: 
ximena# sendmail -d0.1 -bv autolobaz
Version 8.14.5
 Compiled with: DNSMAP LOG MAP_REGEX MATCHGECOS MILTER MIME7TO8 MIME8TO7
		NAMED_BIND NETINET NETINET6 NETUNIX NEWDB NIS PIPELINING SCANF
		STARTTLS TCPWRAPPERS USERDB XDEBUG

============ SYSTEM IDENTITY (after readcf) ============
      (short domain name) $w = ximena
  (canonical domain name) $j = ximena.neolocation.net
         (subdomain name) $m = neolocation.net
              (node name) $k = ximena
========================================================

autolobaz... deliverable: mailer local, user autolobaz
ximena#
 
I don't know what you mean by no activity in /var/log/maillog. If you send an email to your address, and your inbound email is directed to your FreeBSD server, you should see something in the log, regardless of whether the message is actually accepted/delivered or not. If you don't, I would suspect that external connections aren't making it to port 25 on your server at all.

Also, there *is* activity in your log (for the email sent Oct 31 @ 10:45 at least), and I'll eat my hat if that email has not been delivered to your mail file - /var/mail/autolobaz.
I'm starting to wonder if it's the way you're checking your mailbox that is the problem? Can you confirm that /var/mail/autolobaz does not contain the email sent from Google at 10:45?
 
Well your server looks to be configured correctly as far as I can see. If you get nothing at all in the maillog, but are receiving a 550 error then I would suggest the emails are not making it to your server at all. If your server was giving the relaying denied response, it WOULD be in the maillog.

How are the messages getting to your server? Are you pointing Mx records directly to your server or do they go somewhere else that's *supposed* to be redirecting them to your server?
 
My server is VPS. There is no DNS service inside. I had asked my provider about MX records for my sever and they told that if I can ping mail.autolobaz.by it means the problem is in my e-mail server.

autolobaz.by mail exchanger = 0 mail.autolobaz.by.
mail.autolobaz.by internet address = 91.149.189.242
 
Ok, so mail for autolobaz.by is handled by mail.autolobaz.by, which points to 91.149.189.242.

However, if I connect to that IP address on port 25 (as if I were another mail server trying to deliver email) I get a server called mars.neolocation.net, running Exim.

As I guessed in my last post, email for @autolobaz.by is not getting to your Sendmail server at all. It's going to mars.neolocation.net which is probably where your relay error comes from.

If you want ximena.neolocation.net to handle email for autolobaz.by I would suggest you change the MX record from mail.autolobaz.by -> ximena.neolocation.net. Alternatively, you could just change the A record for mail.autolobaz.by to point to 178.172.148.149 instead (the IP address of ximena).
 
SOLVED!!!!! Thank you very much for your detailed explanation and expert support. DNS record was changed and everything work fine now.
 
You must log in or register to reply here.
Back
Top