Re: Opensmtpd failover
If I only knew what others use when they do this successfully then all my problems would be solved. Just kidding. However here is a try. In 1998 I was a sysadmin and our setup was with sendmail and postfix not smtpd. We had 3 Sun Ultra Sparc computers connected with a small switch to a Netapp NFS filer, the MX priority was all the same in DNS so as to achieve a load-share (probably not a true share). The problems back then were NFS related particularily locking meaning the Sun computers ran Solaris because it at the time did this best. Back then it was proper to have backup MX's too I think with a higher priority field in DNS, this ran postfix and all they did was queue the mail and wait for the main mail hosts to come back from whatever caused them to be down, then they'd deliver the mail there. It was just a relayer. You can try making a NFS solution, but the NFS filer is a single point of failure itself, ours had multiple power supplies and I was there too short a time to see it work over a few years. I don't know how well CARP'ed NFS servers behave, I don't know if it creates problems, that's for you to find out. I also don't know how well the locking works with NFS and OpenBSD these days. A solution is to use dot-lock files which gets its atomicity around an NFS stat operation (if that even exists, if not then open operation). The removal of the single point of failure is the tough part, it isn't simple, IMO. Now that I've tried giving you insights to the holy grail of mail, I wish you luck building your own system. Regards, -peter On 11/24/18 1:15 AM, Mik J wrote: Hello, I'm wondering how to do a proper mail server failover. Let's say smtp1 is down, the internet client resolves the other mx with a lower priority and the mail goes to smtp2. Now smtp2 writes the message on the disk in order to store it. What do you people do in order to have a common storage for both smtp which can be correct regardless whether a smtp goes up or down. How do you manage the failover ? Thank you -- You received this mail because you are subscribed to misc@opensmtpd.org To unsubscribe, send a mail to: misc+unsubscr...@opensmtpd.org
Re: Opensmtpd failover
On Sat, Nov 24, 2018 at 06:52:00PM +, Craig Skinner wrote: > Hi Peter, > > On Sat, 24 Nov 2018 08:21:46 +0100 "Peter J. Philipp" wrote: > > > ... the MX priority was all the same in DNS ... > > This is a vastly different scenario to Mik's question. Not the same... > > > > backup MX's too I think with a higher priority field in DNS, > > ... all they did was queue the mail and wait for the main mail hosts > > to come back from whatever caused them to be down, then they'd > > deliver the mail there.??It was just a relayer. > > Yes, that is what Mik was asking about;- The MX backup servers spool > mail while the primary mail servers are down, then relay over SMTP when > the primary can recieve the spooled mail. > > > > ... A solution is to use dot-lock files ... > > Maildirs solve the hideous problems of mboxes... whether on NFS or not. This is good advice. I'm gonna try this in the future. I read about this on wikipedia and it seems to me every message is in its own file. Would it be easy to unison (2 way rsync) mail that's in the new folder to a backup and thus keep them synced for failover? Happy Sunday! -peter -- You received this mail because you are subscribed to misc@opensmtpd.org To unsubscribe, send a mail to: misc+unsubscr...@opensmtpd.org
connect to cyrus lmtp with "as user"
Hi,
I'm somewhat at a dillema. I'm on OpenBSD 6.3 and upgraded the CVS tree for
smtpd to -current. With this I wanted to achieve configuring the smtpd for
an upgrade to 6.4. However my old config does not fit after having translated
it to 6.4 syntax.
The host in question is an internal LAN host that fetchmail's mail from my VPS
and inserts it into cyrus imapd so that the LAN here can use IMAP. The line
in the smtpd.conf used to say this:
accept for local alias deliver to lmtp "/var/imap/socket/lmtp" as
_cyrus
And the new action I have this:
action "local" lmtp "/var/imap/socket/lmtp" alias
In a ktrace dump I get this then due to the missing "as":
78041 mail.lmtp CALL connect(3,0x7f7dea30,106)
78041 mail.lmtp STRU struct sockaddr { AF_LOCAL, "/var/imap/socket/lmtp" }
78041 mail.lmtp NAMI "/var/imap/socket/lmtp"
78041 mail.lmtp RET connect -1 errno 13 Permission denied
Does anyone know off hand how to fix this, either on smtpd or on cyrus's side?
Thanks a lot and seasons greetings,
-peter
--
You received this mail because you are subscribed to misc@opensmtpd.org
To unsubscribe, send a mail to: misc+unsubscr...@opensmtpd.org
Re: connect to cyrus lmtp with "as user"
On Wed, Dec 26, 2018 at 05:37:49PM +0100, Peter J. Philipp wrote: > 78041 mail.lmtp NAMI "/var/imap/socket/lmtp" > 78041 mail.lmtp RET connect -1 errno 13 Permission denied > > Does anyone know off hand how to fix this, either on smtpd or on cyrus's side? > > Thanks a lot and seasons greetings, > -peter Ahh never mind. I checked the path and it was in /var/imap that the permissions were at 750 by default. I changed them to 755 and now it works. Regards, -peter -- You received this mail because you are subscribed to misc@opensmtpd.org To unsubscribe, send a mail to: misc+unsubscr...@opensmtpd.org
Re: Unable to relay email
Hi, I'd like to help you, but I'm late to the thread and some parts were deleted by me by accident. I think we may need to clear up some things first: 1. When you attempt to relay through Bell's smtp relay are you sending mail as y...@bell.ca or any of the domains that falls under bell's domains? Perhaps they implemented a block that prevents you@home.local, or better even y...@anythingotherthanbell.ca. What I'm trying to guess at is that bell refuses to relay for anything other than its domains. 2. Use port 587, check connection with 'openssl s_client -connect host:587 -starttls smtp' 3. Use section D.1 of RFC 5321 to help you write a test mail, use RFC 4954 to help you construct a needed authentication, section 4.1 has an example. Steps are a) connect b) ehlo c) auth d) mail from e) rcpt to f) data g) quit 4. once you have achieved sending a test mail through the bell relay reflect what you did into your config. Try sending as root@home.local and see it fail or not fail, try sending as y...@bell.ca and see it fail or not fail. Know the capabilities (protocol and behaviour) of the bell relay. I hope that helps in any way. Also just 535 doesn't tell me anything when I checked it up in RFC 5321 other than that it's a permanent failure. Was there an error string appended to this code? Regards, -peter On 4/6/19 6:45 PM, Juan Trippe wrote: Can you authenticate with openssl? No, I got the user and password prompts but auth failed. Ok, lets rethink this. Assuming it stopped working the moment the system got rebooted. Than there once was a working configuration, that can be recreated. But if it stopped working around the time of the reboot there is the possibility the provider changed something, making it incompatible with OpenSMTPD. (Than it would be nice to have real hostnames.) It's possible something with the provider changed but I don't think so. I called them and they told me to use my browser. This is my host and the source of the connection info I use: https://support.bell.ca/internet/email/how-to-use-bell-mail?step=5 You could try: action "relay" relay host smtps://my_re...@smtphm.example0.co.jp:465 auth No route available or: action "relay" relay host smtp+tls://smtphm.example0.co.jp No auth table: When auth is appended I get the same 535 auth failed. (I assume you use smtpd only to send system message to your personal inbox on smtphm.example0.co.jp. So maybe sending to someone on the system doesn't require authentication.) Yes, that's what I'm using it for basically. I get local "daily output" emails from "r...@local.home" sent to "r...@local.home". Note: the domain is "local.home" and not "local.home.org" which is what it is when I try to send to external addresses. -- You received this mail because you are subscribed to misc@opensmtpd.org To unsubscribe, send a mail to: misc+unsubscr...@opensmtpd.org
Re: Unable to relay email
On 4/7/19 4:54 AM, Juan Trippe wrote: Hello Peter, Good morning. 1. When you attempt to relay through Bell's smtp relay are you sending mail as y...@bell.ca or any of the domains that falls under bell's domains? Perhaps they implemented a block that prevents you@home.local, or better even y...@anythingotherthanbell.ca. What I'm trying to guess at is that bell refuses to relay for anything other than its domains. When it was working the sender was y...@local.home.org After it stopped working I made a /etc/mail/mailname file (which I've since removed) with sympatico.ca and tried sending as different senders but no luck. I tried different accounts and changing the passwords, still nothing. 2. Use port 587, check connection with 'openssl s_client -connect host:587 -starttls smtp' I tried that and previously "openssl s_client -debug -starttls smtp -crlf -connect host:25", and after the certificate I get: That string I gave you needs improvement, add a -quiet so that it doesn't renegotiate upon R for RCPT TO: --- 250 STARTTLS AUTH LOGIN 334 VXNlcm5hbWU6 BASE64USERNAME 334 UGFzc3dvcmQ6 BASE64PASSWORD 535 Authentication failed Maybe you should use PLAIN instead of LOGIN. I tried to find a good example for this in the RFC's but resulted reading the smtpd source on how to do this. Anyhow start skimming RFC 4616, and read the smtpd source around line 315 in smtp_client.c it seems the Realm or authzid is blank, so you can construct an AUTH PLAIN string like so: printf "\0username\0password" | openssl enc -a I tested this with my username and password on opensmtpd and was able to relay through it so this fashion works. 3. Use section D.1 of RFC 5321 to help you write a test mail, use RFC 4954 to help you construct a needed authentication, section 4.1 has an example. Steps are a) connect b) ehlo c) auth d) mail from e) rcpt to f) data g) quit 4. once you have achieved sending a test mail through the bell relay reflect what you did into your config. Try sending as root@home.local and see it fail or not fail, try sending as y...@bell.ca and see it fail or not fail. Know the capabilities (protocol and behaviour) of the bell relay. Going off this: https://tools.ietf.org/html/rfc4954#section-4.1 S: 220-smtp.example.com ESMTP Server C: EHLO client.example.com S: 250-smtp.example.com Hello client.example.com S: 250-AUTH GSSAPI DIGEST-MD5 S: 250-ENHANCEDSTATUSCODES S: 250 STARTTLS C: STARTTLS I get: 250 STARTTLS EHLO 250-mtlspm02.bell.net 250-HELP 250-XREMOTEQUEUE 250-ETRN 250-CHUNKING 250-BINARYMIME 250-AUTH=LOGIN PLAIN 250-AUTH LOGIN PLAIN 250-PIPELINING 250-DSN 250-8BITMIME 250 SIZE 36700160 STARTTLS 502 You are not authorized to use SSL when you pass -starttls smtp to openssl s_client you're already starttls'ed so no need to do it again. Sorry this was misleading. I hope that helps in any way. Also just 535 doesn't tell me anything when I checked it up in RFC 5321 other than that it's a permanent failure. Was there an error string appended to this code? This is the line from smtpd -dv that had the error: c41771ec2113e5d0 mta error reason=AUTH rejected: 535 Authentication failed Thanks for the ideas, hopefully this will get sorted soon No problem, hope it works for you. I'm gonna try to donate some money to Gilles for my efforts to teach raw SMTP which has little to do with opensmtpd. Regards, -peter -- You received this mail because you are subscribed to misc@opensmtpd.org To unsubscribe, send a mail to: misc+unsubscr...@opensmtpd.org
how could a safety mechanism be configured?
Hi, This is sorta a feature request, but may be solveable by a better config: https://marc.info/?l=openbsd-misc&m=155670259203430&w=2 What I did was explained there. Here is my config for the mail system in question: ---> ... some keys cut ... listen on lo0 listen on ix1 tls auth table aliases file:/etc/mail/aliases table secrets file:/etc/mail/secrets action "local" lmtp "/var/imap/socket/lmtp" user _cyrus alias action "relay" relay tls no-verify host smtps://la...@mail.solarscale.de \ auth match for local action "local" match for any action "relay" match auth from any for any action "relay" <--- So what happened to me was that I activated a crontab accidentally that fetchmails POP3 mail. It connects to localhost and delivers to me (pjp@localhost). In my case the lmtp delivery caused a no such mailbox error, and opensmtpd then sent a bounce to the originators of the mail as MAILER-DAEMON via the relay. How can I in future prevent this through the config? If not possible, is it simple to somehow work out a workaround for such situations? I'm just lucky OpenBSD mailing lists seem to have a catch for such bounces, but I still had to say sorry. Regards, -peter -- You received this mail because you are subscribed to misc@opensmtpd.org To unsubscribe, send a mail to: misc+unsubscr...@opensmtpd.org
Re: how could a safety mechanism be configured?
On Thu, May 02, 2019 at 02:17:27AM +0200, Thomas Bohl wrote: > Hello, > > > So what happened to me was that I activated a crontab accidentally that > > fetchmails POP3 mail. It connects to localhost and delivers to me > > (pjp@localhost). In my case the lmtp delivery caused a no such mailbox > > error, and opensmtpd then sent a bounce to the originators of the mail as > > MAILER-DAEMON via the relay. How can I in future prevent this through the > > config? > > Let fetchmail directly deliver to /var/imap/socket/lmtp should do the trick, > because no bouncing smtpd is involved. Thank you for the hint! I finally have it working with directly delivering to lmtp. No more accidental bounces I hope! Best Regards, -peter -- You received this mail because you are subscribed to misc@opensmtpd.org To unsubscribe, send a mail to: misc+unsubscr...@opensmtpd.org
request (privately) for maillog
Hi, I got another "bouncing messages from misc@opensmtpd.org" message. The particular message was 4669 that bounced. Yet I have no record of this in my maillog, so I suspect a DNS fault. Feb 24 12:07:04 was the time when the 4668 message came to me so I suspect that 4669 came after. I do have a query log for DNS and isolating the fault requires perhaps having some logs from opensmtpd.org for the mail to me (if possible). These logs should state if it was a DNS fault in their own wording. Every answered DNS packet should be accounted for. I have a fairly good idea of one of the vultr nameservers that opensmtpd.org uses but there is other addresses like IPv6 addresses that I'm not sure of. Being given a list of the nameservers would help me in the debug as well. Would opensmtpd.org be able to provide me the logs so I can attempt tracking the problem? Best Regards, -peter
Re: "bouncing messages from ..." (was: request (privately) for maillog)
On Wed, Feb 26, 2020 at 07:40:10AM +, gil...@poolp.org wrote: > > I can confirm it is an issue with mlmmj, there's no failed SMTP attempt > > for any of you who reported getting this message. > > > > found out. > > upon restart of the MX @ opensmtpd.org, the list goes through greylisting > and the first session gets bounced once. I sometimes restart several time > to test diffs which explains why at times people get more of these, and I > obviously did a restart when the errata was published. > > I changed the config so it doesn't go through greylisting again. Thanks Gilles for the quick debug and fix! Best Regards, -peter
how to match my relay rules against a list of IP's?
Hi, Is this possible? This is what I got but it gives me an error... arrowhead# smtpd -dvvv /etc/mail/smtpd.conf:34: table "mylocalhosters" may not be used for from lookups arrowhead# grep mylocalhosters smtpd.conf table mylocalhosters file:/etc/mail/localhosters match auth from src for any action "relay" OS and smtpd are OpenBSD 6.6 with patches. Regards, -peter
Re: how to match my relay rules against a list of IP's?
On Fri, Mar 20, 2020 at 08:51:50PM +0100, Thomas Bohl wrote: > Hi > > > Is this possible? > > Yes > > > This is what I got but it gives me an error... > > > > arrowhead# smtpd -dvvv > > /etc/mail/smtpd.conf:34: table "mylocalhosters" may not be used for from > > lookups > > arrowhead# grep mylocalhosters smtpd.conf > > table mylocalhosters file:/etc/mail/localhosters > > match auth from src for any action "relay" > > Looks ok. > What does your /etc/mail/localhosters look like? arrowhead$ more /etc/mail/localhosters [::1]/128 I also tried without the [] brackets but that did the same error. Regards, -peter
Re: mail log oddity
I had the same IP connect to me, with the same failed-command. -peter On 2020-06-12 02:02, Edgar Pettijohn wrote: On Thu, Jun 11, 2020 at 04:26:37PM -0700, Niklas wrote: I'm curious what this would actually accomplish on a vulnerable server. There's no path or executable its trying to find in its iterations. This looks more like an arbitrary shell command meant to act as a scan/test to find vulnerable servers without fully leveraging the exploit. If you had the IP it originates from it could tell you a lot.On Jun 10, 2020 8:08 PM, Ryan Kavanagh wrote: 61.148.74.134 Edgar On Wed, Jun 10, 2020 at 10:00:08PM -0500, Edgar Pettijohn wrote: Saw this in the maillog today. Any ideas what they are trying to do? ?? 249c054a86af9328 smtp failed-command command="MAIL FROM: <;for i in 0 1 2 3 4 5 6 7 8 9 a b c d;do read r;done;sh;exit 0;>" result="530 5.5.1 Invalid command: Must issue an AUTH command first" My guess is that they're trying to exploit CVE-2020-7247. Search the advisory text for that command: https://www.qualys.com/2020/01/28/cve-2020-7247/lpe-rce-opensmtpd.txt Best, Ryan
Re: smtp-out: Address family mismatch
Hi, I had these when I changed my secrets password, smtpd needs to be restarted after. Regards, -peter On 2020-07-20 11:14, Harald Dunkel wrote: Currently I have 100+ EMails queued with "Network error on destination MX". This is a severe regression since OpenBSD 6.6. Every insightful comment is highly appreciated Harri On 7/6/20 9:01 AM, Harald Dunkel wrote: Hi folks, I see a lot of outgoing EMails queued with a message "smtp-out: Address family mismatch" in the log file. My colleagues don't like EMails being put on hold at all. Prior to 6.4 there was a limit mta inet4 The upgrade guide to the new smtpd.conf syntax (https://www.openbsd.org/faq/upgrade64.html) mentioned "set and limit removed as main keywords" and a new "mta namespace", but smtpd.conf(5) is insufficient in this aspect. It doesn't tell. https://poolp.org/posts/2018-05-21/switching-to-opensmtpd-new-config/ doesn't tell, either. My current (new-style) smtpd.conf has a line action "relay_external" relay src 192.168.1.1 helo "mail.example.com" i.e. the AF is implicitly defined, but as the AF mismatch messages indicate this is not sufficient. Could you please elaborate? Regards Harri
dmarc
Hi, This is sorta a feature request. A lot of people use dmarc to check for incoming mails. Is there a way to turn off dmarc checking in the smtpd? This would be valuable for trusted sources such as mailing lists. Let me give you an example. I mail 1000 bytes to openbsd-misc and there is thousands of recipients on that mailing list. When their software delivers to these thousands I get a DNS request (I'm predicting 40 bytes in the question, and no less than 40 bytes in the answer * thousands) that's already a minimum of 80K bytes DNS traffic generated by a 1K byte mail. It would be cool if OpenBSD could set a "X-DMARC-VERIFIED" header or something and based on a policy on every smtpd that receives this no dmarc dns request is caused. This would make me very happy. Is this all technically possible? Best Regards, -peter
Re: dmarc
On Sat, Jul 25, 2020 at 01:43:23PM +0200, Martijn van Duren wrote: > I'm not 100% sure what you mean, but let me give it a best effort. > > On Sat, 2020-07-25 at 11:00 +0200, Peter J. Philipp wrote: > > Hi, > > > > This is sorta a feature request. A lot of people use dmarc to check for > > incoming mails. Is there a way to turn off dmarc checking in the smtpd? > > This would be valuable for trusted sources such as mailing lists. > > This reads as if you want to disable checking on the receiving end, > which is smtpd. This is not needed since smtpd has no support for > DMARC, SPF, or DKIM verification at this moment. Oh sorry then. Well maybe keep it in mind in the future when this functionality is put into OpenSMTPD, perhaps then. Right now it's super annoying doing any posting, not that I can't handle it, it's more the economic footprint of posting. Let me try to explain below. > > Let me give you an example. I mail 1000 bytes to openbsd-misc and there is > > thousands of recipients on that mailing list. When their software delivers > > to these thousands I get a DNS request (I'm predicting 40 bytes in the > > question, > > and no less than 40 bytes in the answer * thousands) that's already a > > minimum > > of 80K bytes DNS traffic generated by a 1K byte mail. > > If you're worried about those numbers I would stop hosting DNS yourself > and just put it at a company who can handle it. I don't know if you're old enough to remember what a slashdotting is. In effect with all these dmarc requests out there you get a little slashdotting and it makes writing on small hosts to large mailing lists costly. This does have a natural "put your money where your mouth is", but it has an unneeded economical footprint. We're talking thousands of packets and MB of volume for 1 little post (especially when you have DNSSEC enabled and reply with a proof of non-existance to everyone). Now you can imagine where this goes when there is a large ML and everyone posts on it. Different parts of the Internet are lighting up and it's really a waste of electricity. > > It would be cool if OpenBSD could set a "X-DMARC-VERIFIED" header or > > something > > and based on a policy on every smtpd that receives this no dmarc dns request > > is caused. This would make me very happy. > > I'm not aware of this mail header, nor is google. Also this would make > your mail susceptible for a man in the middle to disabling DMARC. > > But if you want this header you should be able to do this quite easily > with a custom filter. The documentation is not installed by default, but > a draft is available in the smtpd soures: smtpd-filters.7. Something like this would be very good. The individual person will not care. So it's left to the makers of mail software to do something (if only for the need to burn less coal to make electricity). I may be noone but I think it's worthy raising this as the trend especially in the OpenBSD community is to be a small guy with a small self run network (I'm part of that). In effect this independence is causing a miscalculated evil. I'm just viewing this and saying "this could get out of control!". Oh I can handle it, but what if we grow 10x, 100x, 1000x, 1x do I want to see this or do I sign off the mailing lists? If email was more like a multicasting it would be very efficient, but then opensmtpd also wouldn't be needed anymore. So we need to be aware of the faults and side-effects of large unicasts that cause extra unicast lookups. > > > > Is this all technically possible? > > > > Best Regards, > > -peter > > > martijn@ Best Regards, -peter
Re: smtp-out: Address family mismatch
Hi,
I don't know what this error entails but I took a peek at the source and
found this in mta.c around lines 1575:
if ((c->source->sa &&
c->source->sa->sa_family !=
mx->host->sa->sa_family) ||
(l->family && l->family != mx->host->sa->sa_family)) {
log_debug("debug: mta-routing: skipping host
%s: AF mism
atch",
mta_host_to_text(mx->host));
family_mismatch = 1;
continue;
}
notice there is a DEBUG level log with a conversion indicating which
host it has problems with. Not saying you need to run it in debug mode,
but you can to see this message.
Best Regards,
-peter
On 2020-07-23 09:45, Harald Dunkel wrote:
The Network error on destination MX has been resolved.
The Address family mismatch is still open.
smtpctl show queue gives me
a9f755dd88e88083|inet4|mta||u...@example.com|cont...@bugs.debian.org|cont...@bugs.debian.org|1595227438|1595227438|0|27|pending|29446|Address
family mismatch on destination MXs
ebbe485d057fa820|inet4|mta||u...@example.com|xxx...@bugs.debian.org|xxx...@bugs.debian.org|1595227386|1595227386|0|27|pending|29394|Address
family mismatch on destination MXs
Please note the "inet4" and
% host bugs.debian.org
bugs.debian.org has address 140.211.166.212
bugs.debian.org has address 209.87.16.39
bugs.debian.org has IPv6 address 2605:bc80:3010:b00:0:deb:166:212
bugs.debian.org has IPv6 address 2607:f8f0:614:1::1274:39
bugs.debian.org mail is handled by 10 buxtehude.debian.org.
% host buxtehude.debian.org.
buxtehude.debian.org has address 209.87.16.39
buxtehude.debian.org has IPv6 address 2607:f8f0:614:1::1274:39
buxtehude.debian.org mail is handled by 10 mailly.debian.org.
buxtehude.debian.org mail is handled by 10 muffat.debian.org.
Currently telnet 140.211.166.212 smtp fails with Connection refused, but
where is the address family mismatch between inet4 and 209.87.16.39 ?
Regards
Harri
