Re: sendmail errors upon partial upgrade
On Thu, Sep 10, 2015, Jeffrey Bouquet wrote: > opendaemonsocket: daemon Daemon0: cannot find: Can't assign requested address What's your mc file? What's the output of: fgrep Daemon0 /etc/mail/sen*.cf and maybe grep '^O DaemonPortOptions' /etc/mail/sen*.cf ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: sendmail downgrade
On Wed, Mar 26, 2014, Willy Offermans wrote: Note: see README file in case of errors. pic -C op.me | eqn -C -Tascii | groff -Tascii -me | ul -t dumb op.txt ul: unknown escape sequence in input: 33, 133 You are so right and I had looked into the README file, as suggested. However I could not find a hint about the error, so therefore I Hmm, did you look at the right README file? Here it is: Known Problems with some *roff versions If you encounter the error: Unknown escape sequence in input: 33, 133 when trying to create op.txt then set the GROFF_NO_SGR environment variable (see grotty(1) man page), e.g., csh% setenv GROFF_NO_SGR 1 sh$ GROFF_NO_SGR=1; export GROFF_NO_SGR $Id: README,v 8.1 2004/07/20 20:25:10 ca Exp $ PS: if you don't need op.txt, then you can simply ignore the error. ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: sendmail downgrade
On Tue, Mar 25, 2014, Willy Offermans wrote: You are right. The following error occurs: Note: see README file in case of errors. pic -C op.me | eqn -C -Tascii | groff -Tascii -me | ul -t dumb op.txt ul: unknown escape sequence in input: 33, 133 I don't know what it means, if someone has an idea, please... How about reading the output of the command and following the advice? Hmm, why are we putting those instructions there? ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: sendmail downgrade
On Mon, Mar 24, 2014, Willy Offermans wrote: Is there a way to downgrade sendmail to Version 8.14.5? Why would you want to do that? Compiling the source code would be my preferred method... ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: sendmail Broken Pipe Error
On Mon, Mar 24, 2014, Willy Offermans wrote: Mar 24 14:16:01 MyServer sm-mta[11725]: s2ODCWT4011717: SYSERR(root): timeout writing message to MyProvider.com: Broken pipe Mar 24 14:16:01 MyServer sm-mta[11725]: s2ODCWT4011717: to=someaddr...@example.com, delay=00:03:29, xdelay=00:03:26, mailer=relay, pri=1284849, relay=MyProvider.com [XXX.XXX.XXX.XXX], dsn=4.0.0, stat=Deferred Since there is a timeout error, I like to know what sendmail is writing to MyProvider.com The mail message (DATA) -- as the log entry states. Is there a way to debug sendmail to disclose the message written to MyProvider.com and the response from MyProvider.com. I'm pretty sure that There's no response... check out s2ODCWT4011717 in your mail queue. ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: 5.0-RC2 informal PR: 90 sec sendmail delay
On Wed, Jan 01, 2003, Terry Lambert wrote: Claus Assmann wrote: It's an editorial complaint. I don't like the breaking the program into seperate programs by function. IMO, DJB is wrong, and this does nothing to enhance security. The result of doing this in FreeBSD has been to greatly complicate rc scripts, with the result that sendmail is much less of an unpluggable component that can be replaced with something else, easily, and with little system impact. I understand the security reasoning, based on having to compete with qmail and other packages that claim this seperation magically fixes all security issues. But it's just a propaganda move, and it's not technically justified. There is no magic, this is plain and simple good engineering standard: you need multiple layers of security. You have to minimize the impact of any mistake that can happen. If you are referring to the separation of sendmail into MTA and MSP: this was necessary to get rid of sendmail being set-user-ID root, which is a security risk (as you will probably agree, this isn't marketing, this is real, e.g., sendmail was abused in some cases to exploit bugs in the OS). Nope. I don't agree. I think the change makes things harder, and I don't see a difference in the volume of security advisories (e.g. not a lot of advisories warning about people being able to obtain the $MAILUSER identity through some buffer overflow, rather than root). I can't believe you have written this. Come on, this is trivial. What can you do with root access? What can you do with smmsp group access? Here's the plain and simple reason for the change in 8.12: 8.11.6/8.11.6 2001/08/20 SECURITY: Fix a possible memory access violation when specifying out-of-bounds debug parameters. Problem detected by Cade Cairns of SecurityFocus. This was what triggered finally the switch, which we had put off far too long. Any simple bug somewhere in this huge program or in the environment, e.g.,: 8.10.2/8.10.2 2000/06/07 SECURITY: Work around broken Linux setuid() implementation. On Linux, a normal user process has the ability to subvert the setuid() call such that it is impossible for a root process to drop its privileges. Problem noted by Wojciech Purczynski of elzabsoft.pl. SECURITY: Add more vigilance around set*uid(), setgid(), setgroups(), initgroups(), and chroot() calls. would give someone root access. This is NOT acceptable (IMNSHO). Is that just a propaganda move, and it's not technically justified? At one point, sendmail was getting a lot of crap in the trade press over running suid root... but, IMO, that's all it was: crap. It was just a hook that people could hang marketing arguments against sendmail on, to FUD people into using a different product. Any reaction to FUD is a marketing reaction, unless there's provable technical merit in the decision. See above. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: 5.0-RC2 informal PR: 90 sec sendmail delay
On Thu, Jan 02, 2003, Terry Lambert wrote: Claus Assmann wrote: What can you do with smmsp group access? Send tons of SPAM. Execute code as mailuser to raise my priviledge to root, and then execute code as root. 8-). Show me a way to do the latter. If you can do that, then it's a bug that needs to be fixed. There have been too many problems in sendmail that caused security holes, even remote root access. The redesign of sendmail will get rid of that, and this includes that there is not set-user-ID root binary and as little code as possible will run as root. If the environment is not secure, then the system is not secure, by definition. For this particular case, the Linux system is going to be insecure, unless you remove all setuid() programs that attempt to drop root priviledges from the system. If it's still possible to See how easy it was to avoid that problem? No set-user-ID root - no root exploit. get in to execute code as the UID of the mail user, then it's possible that the code you execute would be another setuid() program that is succeptible to the problem, and therefore you've only added an extra step to the exploit, rather than eliminated the possiblity. Please show me how. In other words, in this particular case, you have added security through obscurity... which is generally acknowledged as not really increasing security at all. This is not security through obscurity. The general security threat out there is knowledgable attackers who write tools that get into the hands of script kiddies, who are not themselves capable of writing the attacks, but are able to run them just fine, once they are written. Such a change does nothing in defense against the knowledgable attacker. Wrong. It's really a matter of where you put your walls. If I put one stone in wall that needs to removed such that the whole wall collapses then the design of the wall is broken. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: 5.0-RC2 informal PR: 90 sec sendmail delay
On Thu, Jan 02, 2003, Terry Lambert wrote: Claus Assmann wrote: On Thu, Jan 02, 2003, Terry Lambert wrote: Claus Assmann wrote: What can you do with smmsp group access? Send tons of SPAM. Execute code as mailuser to raise my priviledge to root, and then execute code as root. 8-). Show me a way to do the latter. If you can do that, then it's a bug that needs to be fixed. If it's a bug that needs to be fixed, it's a bug in the host OS, and not something that sendmail can address. So your claim is wrong. You can't use the mailuser account to raise your priviledges to root. As I said before, I understand the PR problem of having a remote exploit be a remote root exploit vs. a remote $MAILUSER exploit: Ok, let me say it once: this is B.S. This is not a P.R. problem, it is a real technical problem as I proved to you before. Since this discussion is off-topic for this list and you are not able to prove your point, I stop here. If you want to continue, I invite you to read the sendmail 9 design document and to tell me which of the parts that involve the security features of it are flawed. http://www.sendmail.org/~ca/email/sm-9-rfh.html To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: 5.0-RC2 informal PR: 90 sec sendmail delay
On Wed, Jan 01, 2003, Terry Lambert wrote: I'm not too happy about some of the changes to Sendmail recently, Which? And why? If there are problems, the authors would like to hear about it directly, instead of reading it in some mailing list by accident... but I understand, from a marketing perspective, why they are being made, to compete with DJB's security claims on qmail, and Weitse's claims on seperation of operation on performance (both claims are bogus, but it's complicated to explain to potential customers why that's the case). We are not making changes from a marketing perspective. If you are referring to the separation of sendmail into MTA and MSP: this was necessary to get rid of sendmail being set-user-ID root, which is a security risk (as you will probably agree, this isn't marketing, this is real, e.g., sendmail was abused in some cases to exploit bugs in the OS). To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Journaled filesystem in CURRENT
On Sat, Sep 28, 2002, Zhihui Zhang wrote: Hope I can bother you with two more questions (I know nothing about sendmail beyond its name): (1) Can sendmail be configured to generate automatic messages for the purpose of performance test? No. sendmail is an MTA, not a performance testing tool... There are different load generators available: Netscape has something (I forgot the name), postal is a test program (which I never got to compile), and smtp-source/smtp-sink from postfix. I have also written some load generators, but they require a specific environment. (2) Is each mail stored in its own file? The format of the sendmail mail queue is documented in doc/op/op.* (should be in /usr/share/doc/smm/08.sendmailop on FreeBSD). In brief: it uses two files: data (message body) and envelope / headers / some other routing data. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Journaled filesystem in CURRENT
On Thu, Sep 26, 2002, Alexander Leidinger wrote: On Wed, 25 Sep 2002 11:12:34 -0700 Brooks Davis [EMAIL PROTECTED] wrote: Does CURRENT support journaled filesystem ? There are not journaling file systems in current at this time. Efforts to port both xfs and jfs are underway. We have something better than those. SoftUpdates. Much faster than jfs in metadata intensive operations. But much slower in some other applications. When we tested several filesystems for mailservers (to store the mail queue), JFS and ext3 (in journal mode) beat UFS with softupdates by about a factor of 2. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Journaled filesystem in CURRENT
On Thu, Sep 26, 2002, Terry Lambert wrote: Claus Assmann wrote: When we tested several filesystems for mailservers (to store the mail queue), JFS and ext3 (in journal mode) beat UFS with softupdates by about a factor of 2. Hi Claus! Nice to hear from someone who actually tests things! I think that what you were probably testing was directory entry layout and O(N) (linear) vs. O(log2(N)+1) search times for both non-existant entries on creates, and for any entry on lookup ( / 2 on lookup) . I doubt it. The number of files in the queue directories was fairly small during the runs. Moreover, ReiserFS showed fairly poor performance, even though it should be good for directory lookups, right? The best answer for inbound mail is to go to per domain mail queues, and the best for outbound is to go to hashed outbound domains (as we discussed at the 2000 Sendmail MOTM gathering). Per domain mail queues inbound give you a 100% hit rate on a directory traversal for a queue flush; using hashed outbound directories isn't a 100% hit rate, but you can keep it above 85% with the right hashing structure, which makes the miss rate have only 1-2% impact on processing. Per domain doesn't work easily if you have multiple recipients. Anyway, the new design clearly distinguishes between the content files and the data that is necessary for delivery. If someone is interested: http://www.sendmail.org/~ca/email/sm-9-rfh.html Just as a small data point: I get message acceptance rates of 400msgs/s on a journalling file system (using a normal PC) that writes the data into the journal too. AFAICT that's due to the fact that fsync() is much fast for this kind of storage. The important part for mailservers here is the rate at which content files can by safely written to disk. From my limited experience journalling file systems are here much better than softupdates. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Journaled filesystem in CURRENT
On Thu, Sep 26, 2002, Zhihui Zhang wrote: On Thu, 26 Sep 2002, Claus Assmann wrote: If someone is interested: http://www.sendmail.org/~ca/email/sm-9-rfh.html Just as a small data point: I get message acceptance rates of 400msgs/s on a journalling file system (using a normal PC) that writes the data into the journal too. AFAICT that's due to the fact that fsync() is much fast for this kind of storage. The important part for mailservers here is the rate at which content files can by safely written to disk. From my limited experience journalling file systems are here much better than softupdates. Can you tell me the approximate sizes of these mails and how they are stored? The test for sendmail 9 were made with small sizes (1-4KB). They were stored in flat files using 16 directories. The performance tests for sendmail 8 were done with sizes from 1 to 40 KB, in a single queue directory (AFAIR). To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: sendmail
On Sun, Jun 09, 2002, Riccardo Torrini wrote: I'm unable to hide: X-Authentication-Warning: ...goofy set sender to foobar using -f neither using this m4 macros: define(`confTRUSTED_USERS', ``goofy'') FEATURE(`use_ct_file') Did you add this to submit.mc? Please see cf/README: ++ | MESSAGE SUBMISSION PROGRAM | ++ Notice: do not add options/features to submit.mc unless you are absolutely sure you need them. Options you may want to change include: - confTRUSTED_USERS, FEATURE(`use_ct_file'), and confCT_FILE for avoiding X-Authentication warnings. ... To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
