Re: postfix performance
* Jeroen van Aart jer...@mompl.net: I am curious if postfix would be able to send out 30 emails in one hour, to different recipients of course. Taking into account http://www.postfix.org/TUNING_README.html and other such performance tuning guides. This would only happen once a week or so. The important part is the need to send them all in one hour, more or less. At python.org we're doing 600 msgs/min to remote destinations (gmail, yahoo, hotmail and all the other big one), but mailman cannot create the individual mails (VERP!) as fast as Postfix can send them. -- Ralf Hildebrandt Geschäftsbereich IT | Abteilung Netzwerk Charité - Universitätsmedizin Berlin Campus Benjamin Franklin Hindenburgdamm 30 | D-12203 Berlin Tel. +49 30 450 570 155 | Fax: +49 30 450 570 962 ralf.hildebra...@charite.de | http://www.charite.de
Re: postfix performance
Zitat von Steve Jenkins stevejenk...@gmail.com: On Wed, Mar 23, 2011 at 5:09 PM, Joe j...@tmsusa.com wrote: IMNSHO it's standard practice to run a dns server on the MX host. If you don't want a full blown bind server, at least run some sort of caching dns server; the difference in the lookup times has a big impact when you're sending messages at a high rate. Thx, Joe. Any advantage IYNSHO to running a full blown bind server as opposed to something simpler like dnsmasq or nsd (or anything else you're recommend)? Most of the time simple caching resolvers are faster at corner cases then Bind. Recommended easy to handle caching resolvers are PowerDNS recursor (http://www.powerdns.com) or Unbound (www.unbound.net) for example. Regards Andreas smime.p7s Description: S/MIME Cryptographic Signature
discard specific mails
Good afternoon list. We have a number of clients who have misconfigured applications on their network, which is sending anything from warning to info messages to the developer. Our servers are used as an outbound relay (smarthost) for our clients. Is there a way to filter messages before they are sent out _ example:_ If the mail comes from u...@domain.tld the recipient is anotheru...@anotherdomain.tld the Subject is whatever, then Discard / Reject the message Thanks for your assistance Tom
Re: discard specific mails
On Thu, Mar 24, 2011 at 11:54:03AM +0200, Tom Kinghorn wrote: We have a number of clients who have misconfigured applications on their network, which is sending anything from warning to info messages to the developer. Our servers are used as an outbound relay (smarthost) for our clients. Is there a way to filter messages before they are sent out _ example:_ If the mail comes from u...@domain.tld the recipient is anotheru...@anotherdomain.tld the Subject is whatever, then Discard / Reject the message Headers are only available in the message body (DATA portion of SMTP's dialogue), so you would need a content filter or milter to filter as you have described. http://www.postfix.org/FILTER_README.html http://www.postfix.org/MILTER_README.html If you can figure out how to do this without relying on content, other options are available, including restriction classes and policy servers: http://www.postfix.org/RESTRICTION_CLASS_README.html http://www.postfix.org/SMTPD_POLICY_README.html -- Offlist mail to this address is discarded unless /dev/rob0 or not-spam is in Subject: header
Re: discard specific mails
Tom Kinghorn: Good afternoon list. We have a number of clients who have misconfigured applications on their network, which is sending anything from warning to info messages to the developer. Our servers are used as an outbound relay (smarthost) for our clients. Is there a way to filter messages before they are sent out _ example:_ If the mail comes from u...@domain.tld the recipient is anotheru...@anotherdomain.tld the Subject is whatever, then Discard / Reject the message If you make the rule too specific, no-one will fix their application. The following moves the pain to the party that is making the problem: /etc/postfix/main.cf: smtpd_client_restrictions = check_client_access hash:/etc/postfix/client_access /etc/postfix/client_access: 1.2.3.4 450 4.7.0 Please see http://www.example/whatever for assistance The named webpage has instructions for how to be removed from the blocklist. Once the system/application is cleaned up the rule can be removed and mail will continue to flow. Wietse
Re: discard specific mails
On 3/24/2011 3:09 PM, /dev/rob0 wrote: On Thu, Mar 24, 2011 at 11:54:03AM +0200, Tom Kinghorn wrote: If you can figure out how to do this without relying on content, other options are available, including restriction classes and policy servers: http://www.postfix.org/RESTRICTION_CLASS_README.html http://www.postfix.org/SMTPD_POLICY_README.html I will carry on reading. Thank you for pointing me in the right direction. Regards Tom
Re: discard specific mails
On 3/24/2011 3:10 PM, Wietse Venema wrote: If you make the rule too specific, no-one will fix their application. The following moves the pain to the party that is making the problem: /etc/postfix/main.cf: smtpd_client_restrictions = check_client_access hash:/etc/postfix/client_access /etc/postfix/client_access: 1.2.3.4450 4.7.0 Please see http://www.example/whatever for assistance Thanks for the response. unfortunately most of our clients have dynamically assigned IP addresses. regards Tom
Light A Candle With SocialKonnekt And Pray For Japan
Hi postfix users list , I just light a candle for Japan Victims. Join us to pray for those who have lost their lives and hope for the best for those who have survived. It is time to light a candle and Pray... Please Light a Candle Now at: http://www.socialkonnekt.com/Tsunami/ Warm Regards, bharathan
Re: discard specific mails
Tom Kinghorn: On 3/24/2011 3:10 PM, Wietse Venema wrote: If you make the rule too specific, no-one will fix their application. The following moves the pain to the party that is making the problem: /etc/postfix/main.cf: smtpd_client_restrictions = check_client_access hash:/etc/postfix/client_access /etc/postfix/client_access: 1.2.3.4450 4.7.0 Please see http://www.example/whatever for assistance Thanks for the response. unfortunately most of our clients have dynamically assigned IP addresses. Then trigger on the sender address. /etc/postfix/main.cf: smtpd_sender_restrictions = check_sender_access hash:/etc/postfix/client_access /etc/postfix/sender_access: user@example 450 4.7.0 Please see http://www.example/whatever for assistance Wietse
Re: discard specific mails
On 3/24/2011 3:33 PM, Wietse Venema wrote: Then trigger on the sender address. /etc/postfix/main.cf: smtpd_sender_restrictions = check_sender_access hash:/etc/postfix/client_access /etc/postfix/sender_access: user@example 450 4.7.0 Please see http://www.example/whatever for assistance Wietse Will do. Thank you. Regards Tom
SASL authentication failure: All-whitespace username
Hi, our mail server started to show up a warning about the SASL auth, and I'm starting to get some issue with pop3 and smtp. I'm not able to download the messages on my mail client, and there is some messages that weren't send by our system. I did some research, but couldn't find any useful information related. Could it be a DDoS/Bruteforce attack? There are different IP locations.. most of Brazil, Portugal, US.. Postfix version: postfix-2.7.0,1 Postfix version (fallback): postfix-2.8.1,1 I'm using FreeBSD as server. The /var/log/maillog shows: Mar 24 10:17:10 mailserver postfix/smtpd[9301]: warning: SASL authentication failure: All-whitespace username. Mar 24 10:17:10 mailserver postfix/smtpd[9301]: warning: unknown[XXX.XXX.XXX.XXX]: SASL LOGIN authentication failed: generic failure Mar 24 10:17:11 mailserver postfix/smtpd[9301]: warning: SASL authentication failure: All-whitespace username. Mar 24 10:17:11 mailserver postfix/smtpd[9301]: warning: unknown[XXX.XXX.XXX.XXX]: SASL LOGIN authentication failed: generic failure -- Mar 24 10:17:12 mailserver postfix/smtpd[10175]: warning: SASL authentication failure: All-whitespace username. Mar 24 10:17:12 mailserver postfix/smtpd[10175]: warning: XXX.XXX.XXX.XXX.dsl.telesp.net.br[XXX.XXX.XXX.XXX]: SASL LOGIN authentication failed: generic failure Mar 24 10:17:13 mailserver postfix/smtpd[10175]: warning: SASL authentication failure: All-whitespace username. Mar 24 10:17:13 mailserver postfix/smtpd[10175]: warning: XXX.XXX.XXX.XXX.dsl.telesp.net.br[XXX.XXX.XXX.XXX]: SASL LOGIN authentication failed: generic failure -- Mar 24 10:17:14 mailserver postfix/smtpd[9939]: warning: SASL authentication failure: All-whitespace username. Mar 24 10:17:14 mailserver postfix/smtpd[9939]: warning: XXX.XXX.XXX.XXX.static.ctbctelecom.com.br[XXX.XXX.XXX.XXX]: SASL LOGIN authentication failed: generic failure -- Mar 24 10:17:15 mailserver postfix/smtpd[9939]: warning: SASL authentication failure: All-whitespace username. Mar 24 10:17:15 mailserver postfix/smtpd[9939]: warning: XXX.XXX.XXX.XXX.static.ctbctelecom.com.br[XXX.XXX.XXX.XXX]: SASL LOGIN authentication failed: generic failure -- Mar 24 10:17:15 mailserver postfix/smtpd[10394]: warning: SASL authentication failure: All-whitespace username. Mar 24 10:17:15 mailserver postfix/smtpd[10394]: warning: XXX.XXX.XXX.XXX.dsl.telesp.net.br[XXX.XXX.XXX.XXX]: SASL LOGIN authentication failed: generic failure -- Mar 24 10:17:15 mailserver postfix/smtpd[9129]: warning: SASL authentication failure: All-whitespace username. Mar 24 10:17:15 mailserver postfix/smtpd[9129]: warning: XXX.XXX.XXX.XXX.cslce701.dsl.brasiltelecom.net.br[XXX.XXX.XXX.XXX]: SASL LOGIN authentication failed: generic failure Mar 24 10:17:16 mailserver postfix/smtpd[10394]: warning: SASL authentication failure: All-whitespace username. Mar 24 10:17:16 mailserver postfix/smtpd[10394]: warning: XXX.XXX.XXX.XXX.dsl.telesp.net.br[XXX.XXX.XXX.XXX]: SASL LOGIN authentication failed: generic failure -- Mar 24 10:17:16 mailserver postfix/smtpd[9129]: warning: SASL authentication failure: All-whitespace username. Mar 24 10:17:16 mailserver postfix/smtpd[9129]: warning: XXX.XXX.XXX.XXX.cslce701.dsl.brasiltelecom.net.br[XXX.XXX.XXX.XXX]: SASL LOGIN authentication failed: generic failure Mar 24 10:17:16 mailserver postfix/smtpd[10072]: warning: SASL authentication failure: All-whitespace username. Mar 24 10:17:16 mailserver postfix/smtpd[10072]: warning: XXX.XXX.XXX.XXX.dsl.telesp.net.br[XXX.XXX.XXX.XXX]: SASL LOGIN authentication failed: generic failure Anything that I can do to fix this? Thanks in advance. ps: I know the postfix version is outdated, but I'm waiting until weekend to upgrade it.
Re: postfix performance
On Thu, Mar 24, 2011 at 09:28:21AM +0100, lst_ho...@kwsoft.de wrote: Thx, Joe. Any advantage IYNSHO to running a full blown bind server as opposed to something simpler like dnsmasq or nsd (or anything else you're recommend)? Most of the time simple caching resolvers are faster at corner cases then Bind. Recommended easy to handle caching resolvers are PowerDNS recursor (http://www.powerdns.com) or Unbound (www.unbound.net) for example. None of this matters at 100 requests a second. Any reasonably nearby cache, will suffice. Note that Postfix will run at least 20 processes (if all the mail is to the same destination) and each process only needs to make 5 deliveries a second. Any DNS lookup latency that is substantially below 200ms will do. A LAN DNS server with a 2ms lookup delay is fine. Unbound, bind, ... does not matter. -- Viktor.
Re: SASL authentication failure: All-whitespace username
On Thu, Mar 24, 2011 at 10:42:58AM -0300, Odilo Schwade Junior wrote: Mar 24 10:17:10 mailserver postfix/smtpd[9301]: warning: SASL authentication failure: All-whitespace username. Mar 24 10:17:10 mailserver postfix/smtpd[9301]: warning: unknown[XXX.XXX.XXX.XXX]: SASL LOGIN authentication failed: generic failure Mar 24 10:17:11 mailserver postfix/smtpd[9301]: warning: SASL authentication failure: All-whitespace username. Mar 24 10:17:11 mailserver postfix/smtpd[9301]: warning: unknown[XXX.XXX.XXX.XXX]: SASL LOGIN authentication failed: generic failure Is unknown[XXX.XXX.XXX.XXX] your IP address or the IP address of a zombie doing a brute-force attack? If it is your IP address, perhaps your SASL login name is misconfigured. -- Viktor.
Do I Want SASL
So I have Postfix working great and I've always used webmail if I needed to send email from PC's outside of $mynetworks. So fast forward to today where I got my 1st Android powered mobile phone and I can configure the Android mail client to send/receive IMAP email but my question is do I need to become an open relay to allow my random wireless providers dynamic range of IP's to send mail via Postfix? Seems extremely vulnerable and scary to think I would have to allow my providers IP range to relay mail via my MTA. I started reading a bit and I think I need SASL authentication (correct me please if I'm wrong) and since both Postfix 2.8.1 Dovecot 2.0.11 are configured / using TLS, is there anything else I would need beyond SASL or that you recommend for sending email from my Android powered mobile?
Re: postfix performance
On Thu, Mar 24, 2011 at 8:28 AM, Victor Duchovni victor.ducho...@morganstanley.com wrote: A LAN DNS server with a 2ms lookup delay is fine. Unbound, bind, ... does not matter. Thanks for all the nudges in the right direction. We're now running Unbound on the same box as Postfix, getting cached responses in 0 msec from the Postfix box, and 1 msec responses from all other boxes in the rack. It was as easy as yum install unbound and then editing two lines in the default config file. We'll test this week with a big mailing to see if the overall delivery times are noticeably improved. SteveJ
Re: Do I Want SASL
Carlos Mennens: and I think I need SASL authentication (correct me please if I'm wrong) and since both Postfix 2.8.1 Dovecot 2.0.11 are configured / using TLS, is there anything else I would need beyond SASL or that you recommend for sending email from my Android powered mobile? TLS + SASL should do the job. Also, it is a good idea to configure the droid to connect to port 587 instead of 25, as many providers disallow port 25 traffic (or redirect it to their own SMTP server). Wietse
Re: SASL authentication failure: All-whitespace username
It is not my IP address. I don't know if it's a zombie.. I just think it may be.. XXX.XXX.XXX.XXX = random IPs address. Most of Brazil, Portugal and US as I said earlier. thanks On Thu, Mar 24, 2011 at 1:01 PM, Victor Duchovni victor.ducho...@morganstanley.com wrote: On Thu, Mar 24, 2011 at 10:42:58AM -0300, Odilo Schwade Junior wrote: Mar 24 10:17:10 mailserver postfix/smtpd[9301]: warning: SASL authentication failure: All-whitespace username. Mar 24 10:17:10 mailserver postfix/smtpd[9301]: warning: unknown[XXX.XXX.XXX.XXX]: SASL LOGIN authentication failed: generic failure Mar 24 10:17:11 mailserver postfix/smtpd[9301]: warning: SASL authentication failure: All-whitespace username. Mar 24 10:17:11 mailserver postfix/smtpd[9301]: warning: unknown[XXX.XXX.XXX.XXX]: SASL LOGIN authentication failed: generic failure Is unknown[XXX.XXX.XXX.XXX] your IP address or the IP address of a zombie doing a brute-force attack? If it is your IP address, perhaps your SASL login name is misconfigured. -- Viktor.
Re: postfix performance
On Thu, Mar 24, 2011 at 09:41:25AM -0700, Steve Jenkins wrote: On Thu, Mar 24, 2011 at 8:28 AM, Victor Duchovni victor.ducho...@morganstanley.com wrote: A LAN DNS server with a 2ms lookup delay is fine. Unbound, bind, ... does not matter. Thanks for all the nudges in the right direction. We're now running Unbound on the same box as Postfix, getting cached responses in 0 msec from the Postfix box, and 1 msec responses from all other boxes in the rack. It was as easy as yum install unbound and then editing two lines in the default config file. We'll test this week with a big mailing to see if the overall delivery times are noticeably improved. The DNS cache is unlikely to make much difference for outbound mail, it is much more for incoming mail where you get hammered by zombies. If all you changed was adding a local DNS cache, unless your previous cache was 100ms away, you'll not see much change. To get better treatment from remote systems, get whitelisted by the domains that represent the largest communities of users. -- Viktor.
Re: SASL authentication failure: All-whitespace username
On Thu, Mar 24, 2011 at 02:07:43PM -0300, Odilo Schwade Junior wrote: It is not my IP address. I don't know if it's a zombie.. I just think it may be.. XXX.XXX.XXX.XXX = random IPs address. Most of Brazil, Portugal and US as I said earlier. You can restrict SASL to TLS only, then perhaps fewer zombies will bother. If you get SASL attempts from TLS-enabled zombies, just make sure your passwords are strong enough to not succumb to easy dictionary attacks. -- Viktor.
Re: SASL authentication failure: All-whitespace username
* Victor Duchovni postfix-users@postfix.org: On Thu, Mar 24, 2011 at 02:07:43PM -0300, Odilo Schwade Junior wrote: It is not my IP address. I don't know if it's a zombie.. I just think it may be.. XXX.XXX.XXX.XXX = random IPs address. Most of Brazil, Portugal and US as I said earlier. You can restrict SASL to TLS only, then perhaps fewer zombies will bother. If you get SASL attempts from TLS-enabled zombies, just make sure your passwords are strong enough to not succumb to easy dictionary attacks. You can also use fail2ban to ban (iptables) clients that have X unsucessful SASL login attempts. p@rick -- All technical questions asked privately will be automatically answered on the list and archived for public access unless privacy is explicitely required and justified. saslfinger (debugging SMTP AUTH): http://postfix.state-of-mind.de/patrick.koetter/saslfinger/
Re: postfix performance
On Thu, Mar 24, 2011 at 10:34 AM, Victor Duchovni victor.ducho...@morganstanley.com wrote: If all you changed was adding a local DNS cache, unless your previous cache was 100ms away, you'll not see much change. Actually, after doing some tests with dig on our colo provider's DNS servers we noticed that they were taking an avg of 200+ msec for a reply, and sometimes over 400! We had no idea it was that bad. Again, we're not sure if this change will have any impact on Postfix's delivery times yet, but it's fun to try and optimize. :) To get better treatment from remote systems, get whitelisted by the domains that represent the largest communities of users. Agreed - which we've already done.
Re: postfix performance
On Thu, Mar 24, 2011 at 12:07:06PM -0700, Steve Jenkins wrote: On Thu, Mar 24, 2011 at 10:34 AM, Victor Duchovni victor.ducho...@morganstanley.com wrote: If all you changed was adding a local DNS cache, unless your previous cache was 100ms away, you'll not see much change. Actually, after doing some tests with dig on our colo provider's DNS servers we noticed that they were taking an avg of 200+ msec for a reply, and sometimes over 400! We had no idea it was that bad. Again, we're not sure if this change will have any impact on Postfix's delivery times yet, but it's fun to try and optimize. :) This is not unreasonable for a cache miss, but if this is also the latency for a cache hit, you have a good incentive to avoid this DNS cache. I hope you measured whether a second lookup for the same RRset showed equally long latencies. -- Viktor.
Making my own pipe..
Hi I'm still trying to get Postfix to use deliverquota to deliver the mails to my Maildirs. The only thing I could find on the net was a comment from Magnus http://www.irbs.net/internet/postfix/0412/1673.html that I had to make my own pipe. So this is my attempt: deliverquota unix - n n - - pipe flags=DRhu user=vmail argv=/usr/bin/deliverquota $domain/$recipient One concern - vmail is not a user on my system (and since I copied this from the maildrop pipe, I'm now wondering how mail is delivered at all. My first question is, is $domain/$recipient the way to deliver a Maildir structure that is always domain.tld/user where user is the portion before the @ - this is the way I've understood man pipe, but I'd like to be sure. Do I need it to be unpriv or not? My second question is what happens when deliverquota refuses to deliver the mail because the Maildir is over quota? Does postfix try to deliver a DNS? Thanks.
RE: bcc: header
-Original Message- From: owner-postfix-us...@postfix.org [mailto:owner-postfix-us...@postfix.org] On Behalf Of Reindl Harald Sent: Wednesday, March 23, 2011 1:00 PM To: postfix-users@postfix.org Subject: Re: bcc: header Am 23.03.2011 20:55, schrieb Jeroen van Aart: I tried the following in telnet session, but for some reason the email is only sent to the rcpt to: address. None of the Bcc'ed addresses receive a copy. Am I missing something obvious? rcpt to: n...@example.com 250 2.1.5 Ok data 354 End data with CRLF.CRLF bcc: somen...@example.net, anothern...@example.org testing BCC is a header so why you put it in the mail-body? He didn't. The header is what's before the blank line and the body is what's after the blank line. He has it right in terms of format, but is missing the important details of how SMTP works.
RE: bcc: header
-Original Message- From: owner-postfix-us...@postfix.org [mailto:owner-postfix-us...@postfix.org] On Behalf Of Jeroen van Aart Sent: Wednesday, March 23, 2011 2:21 PM To: Postfix users Subject: Re: bcc: header The post service doesn't care what Cc: you write on your letters either, but only looks at the envelope. Yes, I assumed an MTA may do some extra processing based on the headers added after DATA. MTA history goes back to sendmail, which had three main modes for injecting a message: 1) sendmail user@host [message header and body here] [. or EOF] 2) sendmail -t [message header and body here] [. or EOF] 3) sendmail -bs (or connect via TCP to the SMTP port) 220 ... HELO ... 250 ... MAIL FROM: ... 250 ... RCPT TO: ... 250 ... DATA 354 ... [message header and body here] . 250 ... QUIT 221 ... [close connection] In mode (1) above, the recipient(s) are taken from the command line. In mode (2) above, the recipients are parsed out of the header of the message. In mode (3) above, the recipients are specified by RCPT TO:, which can appear multiple times. The only case where Bcc: actually has its value used is (2). For that matter, that's also the only place the values of To: and Cc: are actually used. I believe postfix presents all of these interfaces one way or another, so if your application is really keen to specify recipients in the header and not via SMTP or the command line, look for the postfix equivalent of (2). But since it seems like you're most of the way toward SMTP support, just add more RCPT TO lines and leave Bcc: since it will very likely be deleted without being used anyway. -MSK
Re: Address Tagging in Postfix?
Le 23/03/2011 01:30, Wietse Venema a écrit : Steve Jenkins: On Tue, Mar 22, 2011 at 4:41 PM, Wietse Venema wie...@porcupine.org wrote: Didn't I write that Postfix will attempt the unextended name first, before trying the name without the text after $recipient_delimiter? I'm assuming you meant extended name first - otherwise I'm confused! :) Yes. I understand that with 'recipient_delimiter = -' Postfix will try to match user-extens...@example.com BEFORE attempting u...@example.com (in most tables). This includes Postfix trying listname-request, owner-listname, and so on, so these addresses will work as expected. Besides this, there is some explicit logic to avoid splitting mailer-daemon, owner-foo and foo-request. But I'm still confused about mouss' advice that I shouldn't use '-' as the delimiter if I'm using mailing list software. As long as 'user-extension' doesn't match any 'listname-command' combinations or match any other valid recipients that include a hyphen before the @, why can't I? I don't know why Mouss believes that this is a problem. - I don't want some admin telling Mr jean that '-' is an extension char so he can use any jean-* but not jean-pierre, jean-marie ... etc. (sure, you can say oh those french people...). I don't have that problem with '+' because '+' doesn't occur in names of people I worked with. - for mailing lists, I don't want listname-randomstring@lists.example to go to listname@lists.example. (yep, this can be solved with access, but why?). just to clarify what I mean: technically there is no problem and the postfix interface is clear. but I wouldn't use '-' as an extension char. that said, I have specific virtual aliases that map some foo-ext to foo+ext. note that I am talking of an extension char that you publish. that is: I tell users: add a +whatever to tag addresses. in which case, I want this to work whatever they do and I don't want things to break because we hire jean-marie after jean.
Re: warning: truncate before-queue filter speed-adjust log: Permission denied
Wietse Venema wrote: Please file a ZFS bug reportug. As per POSIX, when the O_CREAT is specified to open(), The third argument does not affect whether the file is open for reading, writing or for both. In other words, read/write access is controlled with the O_RDWR flags, not the read/write permissions argument. When the above error happens, Postfix discards the file. Consequently, Postfix performance will be reduced, because it creates one extra file per MAIL transaction, instead of one extra file over the process lifetime. Thanks for the insight. Reported: http://www.freebsd.org/cgi/query-pr.cgi?pr=154873 we'll see what comes out of it. Mark ZFS fix has been committed to HEAD! | Re: standards/154873: | ZFS violates POSIX on open/O_CREAT - ftruncate | | State-Changed-From-To: open-patched | State-Changed-By: pjd | State-Changed-When: czw 24 mar 2011 20:28:17 UTC | State-Changed-Why: | Fix committed to HEAD. Thanks! | http://www.freebsd.org/cgi/query-pr.cgi?pr=154873 Mark
Add documentation
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 In IRC, many of us help people test their installations. One of the important tests we stress is using telnet to understand what isn't working as expected. Unfortunately, we haven't been able to find a clear and complete explanation of how to use telnet to interface with an MTA on postfix.org. We are currently pointing people to: http://web.archive.org/web/20060505112108/ http://www.metaconsultancy.com/whitepapers/smtp.htm#s1 And just yesterday we updated the link to be: http://www.freebsdwiki.net/index.php/SMTP,_testing_via_Telnet It would be great if we could keep users in the 'Postfix Universe'. Is it possible to get this information on postfix.org somewhere? If it already is there, my apologies, I haven't been able to find it. Thanks. - -- Munroe Sollog Systems Engineer Digirati Consulting, Inc sol...@digiraticonsulting.com -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) iEYEARECAAYFAk2MBtAACgkQVI0+KepVD/n+BACeLG68cOMkYsyPbq1msnrdVRlg xPwAn2f8O61jpbCG9kCY0HFOKVLpM9gz =nw9f -END PGP SIGNATURE-
