Re: smtpd and virtuals
Here's a couple of manual diffs. smtpd.8 against revision 1.12 ... --- smtpd.8 Wed Oct 12 08:01:04 2011 +++ diffs/smtpd.8 Tue Oct 11 22:56:22 2011 @@ -126,3 +126,16 @@ The .Nm program first appeared in .Ox 4.6 . +.Sh CAVEATS +.Nm +may not be suitable for production use at the present time. +.Pp +It should be noted that while the requisite +.Nm +binaries are included in the default installation, +in cases where there is a corresponding Sendmail utility, +the OpenSMTPD manual page(s) should be fetched from CVS. +Currently this affects +.Xr makemap 8 +and +.Xr newaliases 8 . smtpd.conf.5 against revision 1.45 ... --- smtpd.conf.5Wed Oct 12 09:49:54 2011 +++ diffs/smtpd.conf.5 Tue Oct 11 23:07:18 2011 @@ -217,7 +217,7 @@ The rule matches only locally originating connections. This is the default, and may be omitted. .It Ic from Ar network -The rule matches if the connection is made from the specified +The rule matches if the connection is made from .Ar network , specified in CIDR notation. .El @@ -431,3 +431,16 @@ accept for all relay .Xr smtpd 8 first appeared in .Ox 4.6 . +.Sh CAVEATS +.Xr smtpd 8 +may not be suitable for production use at the present time. +.Pp +It should be noted that while the requisite +.Xr smtpd 8 +binaries are included in the default installation, +in cases where there is a corresponding Sendmail utility, +the OpenSMTPD manual page(s) should be fetched from CVS. +Currently this affects +.Xr makemap 8 +and +.Xr newaliases 8 . I took the liberty of changing the previous diff ... from network The rule matches if the connection is made from the spec- ified network, specified in CIDR notation. ... specified network, specified in CIDR is a little too repetitive for me and unnecessary. Best wishes.
Re: smtpd and virtuals
On Sat, Oct 08, 2011 at 02:40:04PM +0300, Henri Kemppainen wrote: [...] There's something odd about virtuals; though the code I'm running is no longer current (5.0-BETA, to be precise). Here's what makemap.8 says: Virtual domains are kept in maps. To create single virtual address, add ``u...@example.com user'' to the virtual map. To handle all mail destined to any user at example.com, add ``@example.com user'' to the virtual map. [...] I added some debug printfs, and they show that map_stdio_lookup is called with key=virtual.domain. There is no such key, and the mail is rejected. Out of curiosity, I added a matching line to virtual just to see what happens: virtual.domain duclare somebody@virtual.domain duclare [...] I hope Gilles can tell whether this is a documentation bug or code bug. Or maybe I just missed something obvious (such as a sufficiently recent snapshot) :-). Hi, This is actually a feature, not a bug ;-) At RCPT time, smtpd needs to take a decision based on the domain itself before it starts looking at user-parts and take individual decisions. If the map has a key for the domain, then that lookup can be done efficiently for backends that have indexes of some kind. If the map doesn't, then smtpd will have to loop through all keys, comparing their domain parts, until one key matches. A few months ago, when we only supported the db(3) backend, makemap had some code to automagically insert a domain key if you had a virtual entry for a domain. But now that we support various backends, this can't be done anymore as there is just no way of doing it for the stdio(3) (plaintext) backend. This behavior is not specific to OpenSMTPD, at least Postfix has the same need of a domain key as you can observe from man virtual(5): Without this entry, mail is rejected with relay access denied, or bounces with mail loops back to myself. Gilles -- Gilles Chehade http://www.poolp.org/http://u.poolp.org/~gilles/
Re: smtpd and virtuals
On Mon, Oct 10, 2011 at 12:11:28PM +0200, Gilles Chehade wrote: [...] I forgot to mention that this also allows you to very easily disable a virtual domain by simply commenting / uncommenting the domain key Gilles -- Gilles Chehade http://www.poolp.org/http://u.poolp.org/~gilles/
Re: smtpd and virtuals
Hi. In manXX.tgz (since 4.8) and also on web-cgi, the smtpd.conf(5) man page references makemap(8) more than once ... ... with explicit instructions to use that man page as a guide when making db maps and/or understanding the format of plain maps. The web-cgi page obviously hyperlinks to the other page. The makemap(8) man page - again in manXX.tgz and also on web-cgi - contains the following ... NAME makemap - create database maps for sendmail ... and references another associated man page - editmap ... NAME editmap - query and edit records in database maps for sendmail ... both of which reference Sendmail ... ... both of which also reference the sendmail(8) man page ... These breadcrumbs (implicitly and explicitly) eventually also lead to looking at the Sendmail README ... This has been the case for over a year every single time I've looked at web-cgi and on multiple iterations of base ... ... and I've been trying very hard to exhaust myself there before coming here. Suffice to say this is not optimum. http://www.openbsd.org/cgi-bin/cvsweb/src/usr.sbin/smtpd/makemap.8 - smtpd's db maps are incompatible with sendmail's and needs a distinct makemap utility, this is needed for virtual users support amongst other things. links to smtpd's aliases.c and only provides a frontent to parse map descriptions. contains code from pyr@, chl@ and I. Should have also been imported with smtpd. Etcetera. I feel ill. It's somewhat obvious when you do the math between /etc/mailwrapper and /usr/share/man but not obvious enough apparently ... On 10/10/2011, Gilles Chehade gil...@poolp.org wrote: This behavior is not specific to OpenSMTPD, at least Postfix ... That came as quite a surprise. So I go read this ... http://www.postfix.org/virtual.5.html ... and it's quite different from the OpenBSD man pages ... obviously ... ... but it answers a lot of questions ... ... such as why users who are probably much smarter than me (such as Henri) struggle to get this going ... ... and more importantly are apparently asking the wrong questions ... If that's reminiscent of iRobot (Arthur C. Clarke) ... that's exactly how it feels. Asking the wrong questions ... Is this known (AKA are developers installing from source and not seeing this)? Should this be fixed for some definition of fixed? If so, what's a good course of action? - outline it for me, and if I can do, it I will, help me get rid of some of the disappointment. If not, what can be done about users who read the man pages and have issues as a result? - presumably at some point, Sendmail will no longer be in base, man pages will get rotated, this will cease to be an issue. In the interim ... I've apparently wasted a lot of time and enthusiasm on this ... ... but perhaps more importantly I've wasted a opportunities to ask questions about what's really going on and instead I've been asking about things that are irrelevant ... ... the real makemap man page is somewhat cryptic to me and I need to be asking about that. Best wishes.
Re: smtpd and virtuals
Hi Gilles. If my previous is hostile ... sorry. Without the context of the makemap man page in src/usr.sbin/smtpd/ there's no correlation between your first and second mails which creates more confusion. With that man page, however, pennies start to drop ... I spent 4= hours glued to my screen reading and drafting before I understood the full import of what was going on and found some hopefully constructive questions. I was angry about various things but that's down to me. You've done work here. I haven't. Best wishes.
Re: smtpd and virtuals
On Tue, Oct 11, 2011 at 03:14:26AM +1030, David Walker wrote: Hi. Hi, In manXX.tgz (since 4.8) and also on web-cgi, the smtpd.conf(5) man page references makemap(8) more than once ... ... with explicit instructions to use that man page as a guide when making db maps and/or understanding the format of plain maps. The web-cgi page obviously hyperlinks to the other page. The makemap(8) man page - again in manXX.tgz and also on web-cgi - contains the following ... [...] ... both of which reference Sendmail ... ... both of which also reference the sendmail(8) man page ... Seems sensible to me, considering that: ! The *default* MTA for OpenBSD is Sendmail, NOT OpenSMTPD. ! When we switch, the *default* man pages will be updated, but until then the *default* man pages are those of the *default* MTA which you should be running if you can't cope with glitches caused by coexistence of man pages and utilities instaled by the *default* MTA and the one you chose to run ... and that is not the *default* MTA. I hope to have hinted you that you're not running the *default* MTA. http://www.openbsd.org/cgi-bin/cvsweb/src/usr.sbin/smtpd/makemap.8 - smtpd's db maps are incompatible with sendmail's and needs a distinct makemap utility, this is needed for virtual users support amongst other things. links to smtpd's aliases.c and only provides a frontent to parse map descriptions. contains code from pyr@, chl@ and I. Should have also been imported with smtpd. Etcetera. I feel ill. Please, don't read the commit logs then. That message was not intended to be read, let alone understood, by you. It is a comment from a developer to other developers. I fail to understand what point you are trying to make here anyways ... On 10/10/2011, Gilles Chehade gil...@poolp.org wrote: This behavior is not specific to OpenSMTPD, at least Postfix ... That came as quite a surprise. [...] There is a documentation bug. Someone ran into it, kindly asked if it was a documentation bug, which I confirmed along with an explanation of why domain keys are required, and a quote from Postfix's http://www.postfix.org/virtual.5.html (see VIRTUAL ALIAS DOMAINS) to outline that this is not an OpenSMTPD-specific thingie. Man page will be updated to fix the bug, live with it. If so, what's a good course of action? - outline it for me, and if I can do, it I will, help me get rid of some of the disappointment. You can *easily* get rid of the disappointment by running the *default* MTA. If not, what can be done about users who read the man pages and have issues as a result? - presumably at some point, Sendmail will no longer be in base, man pages will get rotated, this will cease to be an issue. In the interim ... In the interim, run the *default* MTA. I've apparently wasted a lot of time and enthusiasm on this ... I've clearly wasted too much time on this mail. -- Gilles Chehade http://www.poolp.org/http://u.poolp.org/~gilles/
Re: smtpd and virtuals
On Tue, Oct 11, 2011 at 04:17:11AM +1030, David Walker wrote: Hi Gilles. Hi, If my previous is hostile ... sorry. [...] I was angry about various things but that's down to me. You've done work here. I haven't. You've outlined it. You've been hostile, you've been angry. We've done the work, you haven't. I'm sure I'll enjoy answering your questions in the future ... -- Gilles Chehade http://www.poolp.org/http://u.poolp.org/~gilles/
Re: smtpd and virtuals
Hi Henri. On 11/10/2011, Henri Kemppainen ducl...@guu.fi wrote: I agree this isn't ideal. On the other hand, having a system ship with two overlapping incompatible alternatives is a rather exceptional case, and there's no way to automagically please everyone. One could suggest renaming the manuals (and binaries?) and installing them both, but that's nasty and ugly, and probably not worth it, if one of the daemons is to be axed anyway. There's surely a good reason smtpd isn't the default yet, and there's a good reason I kept hearing that smtpd isn't considered ready for production yet, back when I started using it. The message is rather clear to me: you may play with it, as long as you know what you're doing, and are okay with the possibility of problems. Finding the manual is a part of knowing what you're doing :-) I can see why one could get confused though, even if the title lines for these (installed) manuals contain sendmail. You are 100% correct about all of that. Including this ... finding the manual is part of knowing what you're doing. It seems to me though, that unless people are actively looking through src for makemap(8) it will easily go unnoticed even for the patch senders. I've been through there maybe a hundred times in the last few months and never noticed it. I go there to look for something specific, find it, move on. Whenever I want documentation I start at man smtpd and go from there. Again though you are 100% correct and we've all been warned. This is why I've tried to understand the situation and tried to laugh about it. I've started drinking now which is helping somewhat ... If not, what can be done about users who read the man pages and have issues as a result? I don't know what can be done about users, but I know what the users can do: try figure out what is lacking or misleading, maybe contact the developer(s), and propose a change. Something like this: Index: makemap.8 === RCS file: /cvs/src/usr.sbin/smtpd/makemap.8,v retrieving revision 1.14 diff -u -p -r1.14 makemap.8 --- makemap.8 3 Sep 2010 11:22:36 - 1.14 +++ makemap.8 10 Oct 2011 19:10:51 - @@ -90,11 +90,14 @@ accept for domain map primary deliver .Ed .Sh VIRTUAL DOMAINS Virtual domains are kept in maps. -To create single virtual address, add -.Dq u...@example.com user +To create a virtual domain, add +.Dq example.com kittens to the virtual map. -To handle all mail destined to any user at example.com, add -.Dq @example.com user +To create a virtual address for one user under that domain, add +.Dq u...@example.com user +to the virtual map. +To catch all mail destined to the domain, add +.Dq @example.com user to the virtual map. .Pp In addition to adding an entry to the virtual map, I'll have a look at that in a minute, well maybe after a good sleep but I don't see any reason not to make some adjustment to smtpd.conf(5) ... That's where the smtpd man pages start to go to makemap(8) ... The next best and as far as I can see other deviation into the Sendmail man pages is from smtpd(8) into mailwrapper. Changing /etc/mailer.conf is discussed there and I don't see any reason not to make it obvious not to follow the breadcrumbs too blindly (i.e.caveats) or maybe a BUGS section. I would like to see smtpd.conf include some warning also and I think it's warranted there more than anywhere. As you say smtpd is known non-production, transitional, so on. Under these circumstances it seems reasonable to me that this information is clearly outlined in all the smtpd specific man pages which it currently isn't. not in any of them that I can see. You and I know this but there are others. Whether or not that happens I see no reason under the same circumstance to be careful when pointing to other man pages that are irrelevant and/or harmful. For instance if I see smtpd and smtpd.conf man pages included can I assume that other included man pages they point to and reference without warning are pointed to and referenced for a reason ... That's what I've assumed. Absent input from Gilles I'll get up tomorrow and do this. It's 7am here ... The need to have a value for the domain key is a bit ugly. I noticed the stdio backend is happy with empty values, allowing for a pretty list under a colon terminated domain name: virtual.domain: user1@virtual.domainuser1 user2@virtual.domainuser2 another.domain: user3@another.domainuser3 user4@another.domainuser4 .. Makemap doesn't like it, though. You're talking a very different language from me. These terms don't appear outside of makemap(8) and maybe newaliases(8) which again I notice is in src ... I pulled makemap(8) from the web last night and had a couple of reads but I really need to take my time with it ... ... but your previous examples were exactly my reaction ... I put this in a draft ... example.com
Re: smtpd and virtuals
On Mon, Oct 10, 2011 at 10:45:37PM +0300, Henri Kemppainen wrote: I don't know what can be done about users, but I know what the users can do: try figure out what is lacking or misleading, maybe contact the developer(s), and propose a change. Something like this: Index: makemap.8 === RCS file: /cvs/src/usr.sbin/smtpd/makemap.8,v retrieving revision 1.14 diff -u -p -r1.14 makemap.8 --- makemap.8 3 Sep 2010 11:22:36 - 1.14 +++ makemap.8 10 Oct 2011 19:10:51 - @@ -90,11 +90,14 @@ accept for domain map primary deliver .Ed .Sh VIRTUAL DOMAINS Virtual domains are kept in maps. -To create single virtual address, add -.Dq u...@example.com user +To create a virtual domain, add +.Dq example.com kittens to the virtual map. -To handle all mail destined to any user at example.com, add -.Dq @example.com user +To create a virtual address for one user under that domain, add +.Dq u...@example.com user +to the virtual map. +To catch all mail destined to the domain, add +.Dq @example.com user to the virtual map. .Pp In addition to adding an entry to the virtual map, As much as I love kittend, a variation of this will be committed shortly :-) The need to have a value for the domain key is a bit ugly. I noticed the stdio backend is happy with empty values, allowing for a pretty list under a colon terminated domain name: virtual.domain: user1@virtual.domainuser1 user2@virtual.domainuser2 another.domain: user3@another.domainuser3 user4@another.domainuser4 .. Makemap doesn't like it, though. Maybe we can solve that -- Gilles Chehade http://www.poolp.org/http://u.poolp.org/~gilles/
Re: smtpd and virtuals
In manXX.tgz (since 4.8) and also on web-cgi, the smtpd.conf(5) man page references makemap(8) more than once ... ... with explicit instructions to use that man page as a guide when making db maps and/or understanding the format of plain maps. [..] This has been the case for over a year every single time I've looked at web-cgi and on multiple iterations of base ... ... and I've been trying very hard to exhaust myself there before coming here. Suffice to say this is not optimum. I agree this isn't ideal. On the other hand, having a system ship with two overlapping incompatible alternatives is a rather exceptional case, and there's no way to automagically please everyone. One could suggest renaming the manuals (and binaries?) and installing them both, but that's nasty and ugly, and probably not worth it, if one of the daemons is to be axed anyway. There's surely a good reason smtpd isn't the default yet, and there's a good reason I kept hearing that smtpd isn't considered ready for production yet, back when I started using it. The message is rather clear to me: you may play with it, as long as you know what you're doing, and are okay with the possibility of problems. Finding the manual is a part of knowing what you're doing :-) I can see why one could get confused though, even if the title lines for these (installed) manuals contain sendmail. If not, what can be done about users who read the man pages and have issues as a result? I don't know what can be done about users, but I know what the users can do: try figure out what is lacking or misleading, maybe contact the developer(s), and propose a change. Something like this: Index: makemap.8 === RCS file: /cvs/src/usr.sbin/smtpd/makemap.8,v retrieving revision 1.14 diff -u -p -r1.14 makemap.8 --- makemap.8 3 Sep 2010 11:22:36 - 1.14 +++ makemap.8 10 Oct 2011 19:10:51 - @@ -90,11 +90,14 @@ accept for domain map primary deliver .Ed .Sh VIRTUAL DOMAINS Virtual domains are kept in maps. -To create single virtual address, add -.Dq u...@example.com user +To create a virtual domain, add +.Dq example.com kittens to the virtual map. -To handle all mail destined to any user at example.com, add -.Dq @example.com user +To create a virtual address for one user under that domain, add +.Dq u...@example.com user +to the virtual map. +To catch all mail destined to the domain, add +.Dq @example.com user to the virtual map. .Pp In addition to adding an entry to the virtual map, The need to have a value for the domain key is a bit ugly. I noticed the stdio backend is happy with empty values, allowing for a pretty list under a colon terminated domain name: virtual.domain: user1@virtual.domainuser1 user2@virtual.domainuser2 another.domain: user3@another.domainuser3 user4@another.domainuser4 .. Makemap doesn't like it, though.
Re: smtpd and virtuals
Hi Henri. On 08/10/2011, Henri Kemppainen ducl...@guu.fi wrote: though the code I'm running is no longer current (5.0-BETA, to be precise Sorry. I should have said version. I don't have the machine here at the moment but it's a 5.0 BETA from about a month ago. I hope Gilles can tell whether this is a documentation bug or code bug. Or maybe I just missed something obvious (such as a sufficiently recent snapshot) :-). I was looking through the archives for this earlier and you've prompted me with some search terms: http://marc.info/?l=openbsd-miscm=127412833020023w=2 I had an issue with aliases a few months back and had a workaround that used domain names: http://marc.info/?l=openbsd-miscm=130506171602880w=2 I thought I might get by and avoid the virtual map but smtpd won't allow relay with aliases. :] I think there was another misc@ thread a month or so ago about this but I can't see it. Best wishes.
Re: smtpd and virtuals
Hi.
inet - hosting.com - mail.hosting.com
smtpd.conf ...
listen on ext
map virtuals { source plain /etc/mail/virtuals.plain }
accept from all for virtual virtuals relay
virtuals.plain ...
postmas...@hosted.com somewh...@gmail.com
[..]
If I send mail to the virtual domain I get bounces back to the
originating server - recipient rejected.
If I check the default log (/var/log/maillog) on the mail machine I
see the mail is getting that far and the same error is there -
recipient rejected.
There's something odd about virtuals; though the code I'm running is no
longer current (5.0-BETA, to be precise). Here's what makemap.8 says:
Virtual domains are kept in maps. To create single virtual address,
add ``u...@example.com user'' to the virtual map. To handle all mail
destined to any user at example.com, add ``@example.com user'' to the
virtual map.
I tried this with a very minimal local setup. smtpd.conf:
listen on lo0
map aliases { source plain /etc/mail/aliases }
map virtual { source plain /etc/mail/virtual }
accept for virtual virtual deliver to mbox
accept for local alias aliases deliver to mbox
virtual:
somebody@virtual.domain duclare
Trying to send to address gets me recipient rejected:
$ echo test|mail somebody@virtual.domain
send-mail: 530 5.0.0 Recipient rejected: somebody@virtual.domain
I added some debug printfs, and they show that map_stdio_lookup is called
with key=virtual.domain. There is no such key, and the mail is rejected.
Out of curiosity, I added a matching line to virtual just to see what
happens:
virtual.domain duclare
somebody@virtual.domain duclare
With this setup, the mail command above works, and my local user receives
the message. Smtpd makes these lookups:
map_stdio_lookup [key=virtual.domain]
aliases_vdomain_exist: 'virtual.domain' exists
map_stdio_lookup [key=somebody@virtual.domain]
aliases_virtual_exist: 'somebody@virtual.domain' exists
map_stdio_lookup [key=somebody@virtual.domain]
aliases_virtual_get: 'somebody@virtual.domain' resolved to 1 nodes
lka_resolve_node: node is local username: duclare
I hope Gilles can tell whether this is a documentation bug or code bug. Or
maybe I just missed something obvious (such as a sufficiently recent
snapshot) :-).
Re: smtpd and virtuals
Documentation bug :-)
Will explain in longer mail when i have access to a computer tomorrow.
Cheers
Henri Kemppainen ducl...@guu.fi a C)critB :
Hi.
inet - hosting.com - mail.hosting.com
smtpd.conf ...
listen on ext
map virtuals { source plain /etc/mail/virtuals.plain }
accept from all for virtual virtuals relay
virtuals.plain ...
postmas...@hosted.com somewh...@gmail.com
[..]
If I send mail to the virtual domain I get bounces back to the
originating server - recipient rejected.
If I check the default log (/var/log/maillog) on the mail machine I
see the mail is getting that far and the same error is there -
recipient rejected.
There's something odd about virtuals; though the code I'm running is no
longer current (5.0-BETA, to be precise). Here's what makemap.8 says:
Virtual domains are kept in maps. To create single virtual address,
add ``u...@example.com user'' to the virtual map. To handle all mail
destined to any user at example.com, add ``@example.com user'' to the
virtual map.
I tried this with a very minimal local setup. smtpd.conf:
listen on lo0
map aliases { source plain /etc/mail/aliases }
map virtual { source plain /etc/mail/virtual }
accept for virtual virtual deliver to mbox
accept for local alias aliases deliver to mbox
virtual:
somebody@virtual.domain duclare
Trying to send to address gets me recipient rejected:
$ echo test|mail somebody@virtual.domain
send-mail: 530 5.0.0 Recipient rejected: somebody@virtual.domain
I added some debug printfs, and they show that map_stdio_lookup is called
with key=virtual.domain. There is no such key, and the mail is rejected.
Out of curiosity, I added a matching line to virtual just to see what
happens:
virtual.domain duclare
somebody@virtual.domain duclare
With this setup, the mail command above works, and my local user receives
the message. Smtpd makes these lookups:
map_stdio_lookup [key=virtual.domain]
aliases_vdomain_exist: 'virtual.domain' exists
map_stdio_lookup [key=somebody@virtual.domain]
aliases_virtual_exist: 'somebody@virtual.domain' exists
map_stdio_lookup [key=somebody@virtual.domain]
aliases_virtual_get: 'somebody@virtual.domain' resolved to 1 nodes
lka_resolve_node: node is local username: duclare
I hope Gilles can tell whether this is a documentation bug or code bug. Or
maybe I just missed something obvious (such as a sufficiently recent
snapshot) :-).
smtpd and virtuals
Hi.
inet - hosting.com - mail.hosting.com
smtpd.conf ...
listen on ext
map virtuals { source plain /etc/mail/virtuals.plain }
accept from all for virtual virtuals relay
virtuals.plain ...
postmas...@hosted.com somewh...@gmail.com
I can send mail from external to local accounts on the box (and alias
them) by various methods - using the ISP provided PTR name and
explicitly accepting mail for that domain, changing the hostname of
the box, fiddling with DNS, so on.
I can send mail from the box to external addresses (including the
gmail address) if I add the appropriate rule and so on.
So ...
I think routing/filtering is fine - mail comes in and mail goes out.
Also, the mail machine is resolving (doing lookups) okay - I can do
host commands from there.
If I send mail to the virtual domain I get bounces back to the
originating server - recipient rejected.
If I check the default log (/var/log/maillog) on the mail machine I
see the mail is getting that far and the same error is there -
recipient rejected.
Sample from my ISP mail server:
Final-Recipient: rfc822;postmas...@hosted.com
Action: failed
Status: 5.0.0 (permanent failure)
Remote-MTA: dns; [w.x.y.z]
Diagnostic-Code: smtp; 5.1.0 - Unknown address error 530-'5.0.0
Recipient rejected: postmas...@hosted.com' (delivery attempts: 0)
That's a good facsimile of what's in the log on the mail machine and
all the domain names and IP addresses are correct.
I've checked smtpctl show (run)queue and they're empty.
It seems that DNS records for both domains (the hosted and the
hosting) are fine as mail sent to the hosted domain makes it the
hosting machine (AKA - it hits the logs).
One thing that concerns me is PTR resource records.
I'm working through that at the moment but it's fair to say if I can
send mail from that machine to the gmail address that's good enough
for now right?
Before I go and set up smtpd logging next week, does this look in the ballpark?
I've spent a couple of days on this over the last month - walking to
the shop and fiddling with the servers and walking home and sending
email ...
Every time I say start logging smtpd I say it should work ... let
me try this first and the walking back and forth begins.
If it's not an obvious error I will be more rigorous.
Best wishes.
