Re: Virtual transport local delivery without bounce
Dne 19.9.2012 v 19:37 Viktor Dukhovni napsal(a):
> On Wed, Sep 19, 2012 at 07:46:06PM +0200, Michal Kurka wrote:
>
> > Hello.
> >
> > I use virtual_transport and my own script for local delivery:
> >
> > main.cf:
> > virtual_mailbox_maps = hash:/etc/postfix/vmailbox
> > virtual_transport = locdel
> >
> > master.cf:
> > locdel unix - n n - - pipe
> > flags=DRXhu user=vmail:vmail
> > argv=/usr/local/bin/MailDelivery.sh ${sender} ${recipient}
>
> If this script is delivering mail to per-user mailboxes, it generally
> cannot do so atomically when the same message arrives for multiple
> users. Therefore it is generally necessary to set the recipient limit
> for this transport to 1.
>
> locdel_destination_recipient_limit = 1
Yes, I know about it, I've had it set.
> > If a mail is arriving from smtpd(8) for local delivery via "locdel" and
> > "MailDelivery.sh" return error, then mail remains in local queue (if
> > temporary error) or generate bounce mail.
> > I need to return SMTP-error to sender server without put in local
> > queue as well as local(8). Is it possible?
>
> No. Postfix delivery is asynchronous.
> http://www.postfix.org/OVERVIEW.html
I'm viewing "http://www.postfix.org/OVERVIEW.html#delivering";. The
local(8) and virtual(8) are at the same level. Why local(8) return
SMTP-error and virtual(8) generate bounce mail?
I tried turn on debug (with debug_peer_level and debug_peer_list). I added
"reject_unverified_recipient" to "smtpd_recipient_restrictions". I see in
maillog that verify(8) tests deliverability using only lookup in
"/etc/postfix/vmailbox", no test execute locdel-transport. This is
logical, because executing a final delivery program causes a delivery
process.
So how to solve it? There is "address_verify_virtual_transport". May
be use external program for "address_verify_virtual_transport" returning
error if mail is not deliverable. Anyone have experience with this?
--
Michal Kurka - Mysak
sluzby spojene s operacnim systemem Linux
Re: Virtual transport local delivery without bounce
Michal Kurka: > > > I need to return SMTP-error to sender server without put in local > > > queue as well as local(8). Is it possible? > > > > No. Postfix delivery is asynchronous. > > http://www.postfix.org/OVERVIEW.html > > I'm viewing "http://www.postfix.org/OVERVIEW.html#delivering";. The > local(8) and virtual(8) are at the same level. Why local(8) return > SMTP-error and virtual(8) generate bounce mail? ALL Postfix delivery agents generate a bounce message upon permanent delivery error. No exceptions. > I tried turn on debug (with debug_peer_level and debug_peer_list). I added > "reject_unverified_recipient" to "smtpd_recipient_restrictions". I see in > maillog that verify(8) tests deliverability using only lookup in > "/etc/postfix/vmailbox", no test execute locdel-transport. This is > logical, because executing a final delivery program causes a delivery > process. ALL Postfix delivery agents generate a "trace" message for address verification. No exceptions. > So how to solve it? There is "address_verify_virtual_transport". May > be use external program for "address_verify_virtual_transport" returning > error if mail is not deliverable. Anyone have experience with this? People use recipient address verification all the time. It works for ALL Postfix delivery agents, without exception. However address verification cannot report errors that can only be discovered by actually delivering mail (mailbox file permission error, command in .forward file does not exist, etc.). It's good for "user unknown" or "host unknown" errors. Wietse
SV: Cleaning out certain 4xx-errors
>In a Postfix pcre_table(5) you must have a space between the >expression closing delimiter, "/" above, and the SMTP code (or >access(5) keyword). Your "551" would thus be misinterpreted as >unknown PCRE flags. Gotcha. Thanks. I read that slightyl backwards at first >You obviously must fix that problem also. That was a bit of a *D'OH*-moment. Yes, Thank you!
Re: The ultimate email server
2012/9/20 Anonymous : >>Thanks a lot everyone! After thinking long and hard about all your advice I >>finally ended up with: >> >>..+ postfix-anti-UCE.txt +.. > > "Ultimate" server, or "cheap" server? > > Postfix-anti-UCE.txt is a poor choice because of the damage it does to > legitimate mail. Although you may be stuck with it if you cannot > afford a server that can do a more intelligent analysis. But if your > resources are too tight to analyse every message, then you can't build > an "ultimate email server". > > DNSBLs are a sloppy way to cut down on traffic - a strategy large > providers use to cut expenses (read: increase profits) at the cost of > legitimate mail. > > An "ultimate" mail server that is built with quality of service in > mind does not use crude techniques prone to collateral damage. > Thank you for your reply. It stands out from all the rest ;) What are these more intelligent, less crude techniques you talk about? Mikkel
DNSBL use (was: Re: The ultimate email server)
On Fri, Sep 21, 2012 at 03:45:11PM +0200, Mikkel Bang wrote: > 2012/9/20 Anonymous : > >>Thanks a lot everyone! After thinking long and hard about all > >>your advice I finally ended up with: > >> > >>..+ postfix-anti-UCE.txt +.. > > > > "Ultimate" server, or "cheap" server? > > > > Postfix-anti-UCE.txt is a poor choice because of the damage it > > does to legitimate mail. Although you may be stuck with it if > > you cannot afford a server that can do a more intelligent > > analysis. But if your resources are too tight to analyse every > > message, then you can't build an "ultimate email server". > > > > DNSBLs are a sloppy way to cut down on traffic - a strategy large > > providers use to cut expenses (read: increase profits) at the > > cost of legitimate mail. > > > > An "ultimate" mail server that is built with quality of service > > in mind does not use crude techniques prone to collateral damage. > > > > Thank you for your reply. It stands out from all the rest ;) I did not see this on the list, was it sent offlist? Indeed it does stand out: offering you fact-free FUD. In the past month have you been running your "ultimate mail server"? If so, look at your own logs. Ask your users. What legitimate mail did your "sloppy" and "crude" ways cost you? Billions of mailboxes worldwide rely on Spamhaus Zen protection. Indeed, it's a low cost means of protection. Other ideas from postfix-anti-UCE.txt, such as reject_non_fqdn_helo_hostname, are likewise safe, effective, and cheap. > What are these more intelligent, less crude techniques you talk > about? Probably more subjective FUD lacking real data, if I were to guess. I'll suggest that followups to this would be better heard on SDLU: http://spammers.dontlike.us/ -- http://rob0.nodns4.us/ -- system administration and consulting Offlist GMX mail is seen only if "/dev/rob0" is in the Subject:
