Re: Success DSNs From Come to Postmaster
On 30 Jan 2012, at 22:20, Wietse Venema wrote: Ralf Hildebrandt: * Sabahattin Gucukoglu m...@sabahattin-gucukoglu.com: Is it a bug or a feature that success DSNs requested for the null sender come to the postmaster? Here's what happens. First, mail to the null address goes to MAILER-DAEMON by default: empty_address_recipient (default: MAILER-DAEMON) The recipient of mail addressed to the null address. Postfix does not accept such addresses in SMTP commands, but they may still be created locally as the result of configuration or software error. Second, it's common to have an alias MAILER-DAEMON - postmaster, so that explains why the mail for ends up there. Right. This makes sense. And the To: field in notifications is empty itself, too. I've set empty_recipient_address to double-bounce, which seems to do what I want, send these to bit heaven. (BTW: it isn't documented anywhere that double-bounce works arbitrarily like this, nor that it's accepted in SMTP as 'double-bounce'.) Postfix sends delivery notifications as mail from . When this first-order notification fails, Postfix will attempt to deliver a second-order notification to the 2bounce_notice_recipient (default: postmaster) as a final attempt to avoid loss of mail. Are these internally-generated bounce messages distinguishable from mail that is actually injected with SMTP or the sendmail command as 'mail from:' or 'sendmail -f '? I assume one of two things must be true in order to receive a double bounce for such mails, either that this is really the case or the bounce handling code follows through, first for a single bounce and then a double bounce, such that a failed message injected with is included directly in the double bounce, rather than inside a single bounce which is included in the double bounce. I never saw the latter, leading me to believe the former assumption, which is that internally generated mail is special. This handling of fail/delay notifications satisfies the RFC's requirement of never responding to the sender address. However, the code that handles NOTIFY=SUCCESS fails to satisfy that RFC requirement. It was written several years earlier to implement support for sendmail -bv and sendmail -v, and was not updated when it was put into service to also handle SUCCESS notifications. I'll make the NOTIFY=SUCCESS handling consistent with fail/delay. Thank you! Cheers, Sabahattin
Success DSNs From Come to Postmaster
Is it a bug or a feature that success DSNs requested for the null sender come to the postmaster? I vote bug. :-) Any workarounds to prevent this in the meantime? Cheers, Sabahattin
Re: Sending NDRs (if any) from different server than normal mails
On 27 Jan 2012, at 23:57, Jeroen Geilman wrote: On 01/26/2012 10:37 AM, Gábor Lénárt wrote: First of all, I know sending NDRs is not a great idea. .. they are a requirement of SMTP. What on Earth posesses you to think they are bad ? An increasingly crackpot attitude towards all forms of backscatter by the Spam fighters and other supposed legions of the light, I suspect. The idea is not to generate bounces in case the sender address is forged. While it's a legitimate concern, it's not enough of a concern to deny senders disposition reports. Those people affected by enough backscatter should seriously consider employing BATV. TMDA also has a built-in address signing mechanism which you should be using anyway if you use TMDA at all to help with this. A very small number of things are affected by SES; whitelist them (EG ezmlm, which has problems of its own worth considering replacing it anyway). However, still, I would like to make things better by passing NDRs to another server: its task is only send out the NDRs, nothing more. It would help to analyze/block the NDR traffic there, also if that server is blacklisted (because of being source of backscatter), it's not a real problem, as normal mails are not sent from there. I have no idea what you mean here. Why should bounces be sent by a different server ? He wants to send bounces through another IP so *that* IP can get blocked. He wants to reduce the effects of getting blocked to just bounces, when one of the legions of the light swoop on him for daring to send backscatter. Example: http://www.backscatterer.org/ . Qmail has this as a patch. Courier has some nice backscatter suppression logic in it, to stop trouble users causing more trouble over a short period of time. These are both reasonable approaches. If you're not already using proper client DNSBL blacklisting, as you seem to indicate above - you're really running a decade behind the times. And if YOU are generating backscatter, then you are not using sufficient restrictions on incoming mail. DO NOT accept mail that you cannot deliver. These are points I'd rather not debate, though not from agreement. I think it is fair to say though that where options exist not to accept mail, according to your policies, then you should not accept that mail. This almost always includes protocol violations, viruses, known spam, MX relay RCPT, etc. It won't include autoresponders, challenge-response, mailing list servers, failed/delayed mail, etc, at least until implementations of some of these come along which reject at SMTP time, where that makes sense. Cheers, Sabahattin
Selecting Client Name Based On IP Version
One of my Postfix installs runs behind a NAT box. The host name for the local private IP is in the .local domain, not suitable for public use in SMTP sessions but suitable for trace fields. However, on IPv6, the host is a first-class citizen on the net and has its own host name. Can I arrange it so that the SMTP client uses different names in the EHLO/HELO command based on the protocol (IPv4 or IPv6) I am connecting with? I do not want IPv6 servers to know my server as natbox.mydomain, but Bloodstone.mydomain. (natbox is the NAT box, anything could run behind that.) more generally: can I arrange it so that I can select the EHLO/HELO name based on the destination host and protocol? Then intra-domain communication can use a local domain name. Cheers, Sabahattin
Where's ORIGINAL_RECIPIENT?
I could sure use it! TMDA when generating challenge messages sends a 'From:' based on the $RECIPIENT variable. Unfortunately, my primary addresses are all aliases, where I'd like those to be canonical, and $RECIPIENT is post-expansion. With the documented ORIGINAL_RECIPIENT to hand, this isn't a big deal until TMDA gets fixed - write a quick wrapper script that calls TMDA with $RECIPIENT set equal to $ORIGINAL_RECIPIENT. However, it isn't set, even where the destination address of the email and the expanded address are clearly different. There's another thought, but I don't know which is safest. Because the aliases are all constant addresses after expansion in the 'From:' headers, and don't contain any extension characters, couldn't I put it into canonical(5) maps? There'd be no interference from SMTP server or clients, and I could always restrict it to just sender header (messages go out with envelope). The only question then is: how do I prevent mail arriving with the aliases expanded over SMTP from remote clients from themselves getting rewritten? Or, I could play with the recipient address of mail inbound. Which does cleanup prioritise, alias expansion or canonical maps? I could undo the $RECIPIENT expansion for the benefit of TMDA for just those aliases using it. Cheers, Sabahattin
Error, Retry, Discard Required?
Hi, Couldn't find any clear answers to this question anywhere in the documentation. I'm not specifically referencing the error, retry or discard transports. Can I keep them commented out in master.cf? Are they used internally? Cheers, Sabahattin
Inserting Select Missing Headers
Hi, I've got an email client (KeyMail, part of KeySoft, a specialised client in the BrailleNote note-takers for the blind) that fails rather gracelessly when messages don't have Message-Id: fields. Being a purist, I *really* don't want to add any headers on mail received from outside, but I must have Message-Id: in this case. Unfortunately, only always adding missing headers is an option in main.cf, but that adds From/Sender/Resent-* as well as the (acceptable) Date: and Message-Id: (To: is controllable separately). Is there any way to uniquely control each header? Or am I going to have to just lump it and always have a From: header derived from the system accounts or envelope sender? Cheers, Sabahattin
Something Lighter Than Forward Address Verification?
Hi, I am thinking about trying to replicate a feature I custom-built for my Sendmail installation, in Postfix. What this does is, whenever a host I am backup for is mentioned in the SMTP RCPT command, I check to see if the host is up, and *refuse* the command (450) if it is. The consequence of that is that spammers, who normally buzz off when told, can be tested by a primary host using all of the techniques at the primary's disposal - DNSBL, greylist, etc. Any SMTP-time refusal is done by the primary, where it makes the most sense, even after the DATA command where verification has no arbitration. Finally, dictionary attacks have less effect since the probe is limited to starting up a connection and reading a banner once for the duration of the cache time. Unfortunately, this doesn't seem to be within the realm of Postfix's recipient address verification. Have I missed anything? Even if I were to set the temporary fail during verification code to 250, I'd potentially accept responsibility for mail I shouldn't regardless of whether the host was really up, if I could not queue verify probes. How can I get the desired effect, or will I need a policy server to do this? Cheers, Sabahattin smime.p7s Description: S/MIME cryptographic signature
Re: additional parameters to the SMTP MAIL and RCPT commands
On 10 Jul 2010, at 00:10, Sufian Hameed wrote: can you please elaborate? what is wrong? RCPT TO:forward-path [ SP rcpt-parameters ] CRLF is the syntax mentioned in RFC 2821. 1. SP is part of the ABNF grammar in the formal specification of the syntax of the command. It means a space character. There is no literal SP in the command. For example: RCPT To:j...@example.org notify=success,failure,delay 2. The SMTP server is not obliged to understand parameters it does not implement. If the EHLO response doesn't include a feature you need, you (as a client) cannot use it. 3. RFC 5321 is the current draft standard, and it's under revision (in the YAM working group of the IETF) to full standard. Cheers, Sabahattin smime.p7s Description: S/MIME cryptographic signature
Local Delivery Without Non-alias Usernames
Hello all, I'm setting up Postfix 2.6, speculatively, reading through the documentation and building my configuration. It appears that the scenario I want is somewhere between virtual and local deliveries. What I want to do: .forward support, /etc/aliases support, detail address (user-foo) support. What I do not want: mail being delivered or accepted to bin, daemon, and other nonsense. The machine is only serving me and my services, all implemented as aliases. My alias is not equal to my username, which itself doesn't get mail and doesn't want it, thank you very much. Therefore, everything is an alias, there will never be, and I don't want, deliveries for non-alias or non-.forward-style deliveries referenced through an alias. Can somebody explain if there is some right way to do this? Am I even thinking along the right lines? Perhaps I should implement this another way. Right now I would be using local(8) and access restrictions to prevent accepting mail for anything not configured in /etc/aliases, but this is somewhat awkward because it means maintaining two separate tables. Cheers, Sabahattin smime.p7s Description: S/MIME cryptographic signature
Re: Local Delivery Without Non-alias Usernames
On 24 Apr 2010, at 13:57, Wietse Venema wrote: Sabahattin Gucukoglu: I'm setting up Postfix 2.6, speculatively, reading through the documentation and building my configuration. It appears that the scenario I want is somewhere between virtual and local deliveries. What I want to do: .forward support, /etc/aliases support, detail address (user-foo) support. What I do not want: mail being delivered or accepted to bin, daemon, and other nonsense. The machine is only serving me and my services, all implemented as aliases. My alias is not equal to my username, which itself doesn't get mail and doesn't want it, thank you very much. Therefore, everything is an alias, there will never be, and I don't want, deliveries for non-alias or non-.forward-style deliveries referenced through an alias. Can somebody explain if there is some right way to do this? Am I even thinking along the right lines? Perhaps I should implement this another way. Right now I would be using local(8) and access I recommend that you make a distinction between inside and outside views. - For the inside view, alias all system accounts (bin, daemon, etc) to the primary user. You don't want to throw away mail that is related to activity by local processes. - For the outside view, set local_recipient_maps to a table that lists only accounts that are to supposed to receive mail from outside the machine. There is no legitimate reason to send mail to (bin, daemon, etc) from outside. /etc/postfix/main.cf: local_recipient_maps = hash:/etc/postfix/local /etc/postfix/local: # bare username, not u...@domain foowhatever bar whatever ... Where whatever can be any non-empty string. http://www.postfix.org/postconf.5.html#local_recipient_maps http://www.postfix.org/DATABASE_README.html#lists Okay, this looks great, but I have clearly missed a beat here, that check is being done in smtpd. Does this mean that recipient_delimiter is checked in smtpd as well as in the delivery agent itself? That's how LOCAL_RECIPIENT_README looks to me. Because if it does, I'm made. :-) I'm clearly spoiled, coming from sendmail. Cheers, Sabahattin
