Re: postfix devnull mailbox

[Dennis Carr]

On Thu, 22 Dec 2011, Sahil Tandon wrote:


Because this thread has veered off into a general discussion about mail
operation/policy, would you consider taking it off-list or to a more
appropriate forum, e.g. the mailop list?


Agreed.  I'm stunned that a tongue in cheek comment of mine has resulted 
in a flame war. =>.<=


-Dennis

Re: postfix devnull mailbox

[Sahil Tandon]

On Fri, 2011-12-23 at 12:10:10 +1300, Peter wrote:

> On 23/12/11 01:53, Stan Hoeppner wrote:
> > On 12/21/2011 5:30 PM, Peter wrote:
> >> There is nothing more frustrating than trying to figure out why your
> >> emails are not going through to your customers than when they are
> >> accepted for delivery and *not* delivered.  I have very little patience
> >> for anyone who insists on doing this.
> > 
> > That's because you're confusing discarding spam with discarding legit
> > mail.
> 
> No.
> ... 

Because this thread has veered off into a general discussion about mail
operation/policy, would you consider taking it off-list or to a more
appropriate forum, e.g. the mailop list?

-- 
Sahil Tandon

Re: postfix devnull mailbox

[Peter]

On 23/12/11 01:53, Stan Hoeppner wrote:
> On 12/21/2011 5:30 PM, Peter wrote:
>> There is nothing more frustrating than trying to figure out why your
>> emails are not going through to your customers than when they are
>> accepted for delivery and *not* delivered.  I have very little patience
>> for anyone who insists on doing this.
> 
> That's because you're confusing discarding spam with discarding legit
> mail.

No.

> Maybe your spam filters or your own special A/S sauce simply suck?

There is no such thing as a 100% accurate SPAM filter.

> The LKML list manager, and many others across the globe, treat 5xx
> rejections of their list mail as bounces, and unsub members after a
> given threshold, 3 IIRC in the case of LKML lists (of which there are
> many dozen, 4 which I sub).

As they should, they risk being flagged as spammers themselves if they
continue to try to deliver to email address that have bounced or rejected.

> I was told I must simply eat the spam along
> with the rest, or not participate.  Yes, this is a stupid draconian
> policy, but I must live by their rules, or not participate.

You won't actually be rejecting emails from these (unless your MTA is
mis-configured) because they are all coming from a legitimate sender.
The best you can hope for is to mark them as SPAM based on the content
in which case they should be delivered to a Spam folder (which would not
trigger an unsub).

> Thus, I DISCARD most of the spam from such lists instead of eating it,
> then manually deleting it, or sorting it to a spam folder and then
> deleting it as you apparently do.  Why do all the extra work when a
> DISCARD does it for me with zero fuss?

Again, see false positives.  They do happen, no matter how good your
filters are.

> This is why I said the world is shades of grey Peter.

Yes, and some emails may look like spam to your filters but actually
aren't.  When you take the draconian solution of discarding everything
that looks like spam then you run the risk of missing important emails.

Oh, and as for the RFCs, have a look at RFC 5321:

4.2.5. Reply Codes after DATA and the Subsequent .


   When an SMTP server returns a positive completion status (2yz code)
   after the DATA command is completed with ., it accepts
   responsibility for:

   o  delivering the message (if the recipient mailbox exists), or

   o  if attempts to deliver the message fail due to transient
  conditions, retrying delivery some reasonable number of times at
  intervals as specified in Section 4.5.4.

   o  if attempts to deliver the message fail due to permanent
  conditions, or if repeated attempts to deliver the message fail
  due to transient conditions, returning appropriate notification to
  the sender of the original message (using the address in the SMTP
  MAIL command).


...which one of the above says it can drop email without delivering it?


Peter

Re: postfix devnull mailbox

[Stan Hoeppner]

On 12/21/2011 5:30 PM, Peter wrote:
> On 22/12/11 04:56, Stan Hoeppner wrote:

>> or discarded.

> There is nothing more frustrating than trying to figure out why your
> emails are not going through to your customers than when they are
> accepted for delivery and *not* delivered.  I have very little patience
> for anyone who insists on doing this.

That's because you're confusing discarding spam with discarding legit
mail.  Maybe your spam filters or your own special A/S sauce simply suck?

>> The world is shades of grey Peter, not black and white.  SMTP RFCs even
>> have grey areas Peter.  I believe they are worded as "may" instead of
>> "should".
> 
> Yes, and the world is full of email admins who don't know what they're
> doing, what was your point again?

The LKML list manager, and many others across the globe, treat 5xx
rejections of their list mail as bounces, and unsub members after a
given threshold, 3 IIRC in the case of LKML lists (of which there are
many dozen, 4 which I sub).  I was told I must simply eat the spam along
with the rest, or not participate.  Yes, this is a stupid draconian
policy, but I must live by their rules, or not participate.

Thus, I DISCARD most of the spam from such lists instead of eating it,
then manually deleting it, or sorting it to a spam folder and then
deleting it as you apparently do.  Why do all the extra work when a
DISCARD does it for me with zero fuss?

This is why I said the world is shades of grey Peter.  In some
circumstances DISCARD simply works, and is a better option than anything
else, including the swallow/regurgitate/spit routine that you preach here.

-- 
Stan

Re: postfix devnull mailbox

[Peter]

On 22/12/11 09:58, Jeroen Geilman wrote:
> In postfix' case, "address verification" does not mean "use the SMTP
> VRFY command".
> It means "send a specially-crafted, actual email message and record
> whether the recipient is accepted or not."
> 
> It is documented in detail here:
> http://www.postfix.org/ADDRESS_VERIFICATION_README.html
> 
> This will fail if, as previously mentioned, your MTA rejects a recipient
> address that was previously allowed to send mail.

Only if you reject the email at the RCPT TO stage.  See rob0's post for
a way to avoid this.


Peter

Re: postfix devnull mailbox

[Peter]

On 22/12/11 05:07, Reindl Harald wrote:
> On 21.12.2011 15:56, Viktor Dukhovni wrote:
>> The real solution is not misuse the "nore...@example.com" *header*
>> address as an envelope sender address.
>>
>> The envelope sender, especially for no-reply automatically generated
>> email, must be a valid mailbox that is capable of receiving and
>> acting on non-delivery reports (bounces).
> 
> have fun getting blacklisted by bounce mails to the noreply-address
> which are spam using a spoofed sender of an existent person!

Huh?  You're talking about backscatter, which makes no sense here.
Viktor was talking about being able to *receive* bounces, not about
sending them.


Peter

Re: postfix devnull mailbox

[Peter]

On 22/12/11 04:56, Stan Hoeppner wrote:
> On 12/20/2011 9:19 PM, Peter wrote:
> 
>> In the case of SPAM the best solution is to deliver the email to
>> the user's SPAM folder 
> 
> You must have an unlimited SAN hardware budget for your 1,000,000
> mailbox site, if you practice what you preach above.

No, of course not, but I know how to deal with disk space limitations.

> Potential FPs
> should be routed to a "spam" folder, if you like.  Everything else
> should be rejected

Yes.

> or discarded.

There is nothing more frustrating than trying to figure out why your
emails are not going through to your customers than when they are
accepted for delivery and *not* delivered.  I have very little patience
for anyone who insists on doing this.

> The world is shades of grey Peter, not black and white.  SMTP RFCs even
> have grey areas Peter.  I believe they are worded as "may" instead of
> "should".

Yes, and the world is full of email admins who don't know what they're
doing, what was your point again?


Peter

Re: postfix devnull mailbox

[Jeroen Geilman]

On 2011-12-21 04:24, Peter wrote:

On 21/12/11 15:19, Reindl Harald wrote:


Am 21.12.2011 01:29, schrieb Peter:

On 21/12/11 13:21, Reindl Harald wrote:

so why does he not use the reply-button and what is he thinking does
"nore...@mail.tld" mean? if you do not read the noreply-address it
is the same as drop the messages, the only difference is on the storage

I am not excusing the sender's actions, I am simply stating that if you
are going to accept an email for delivery then you should deliver it, to
do otherwise gives a false impression to the sender.

but this is not solveable in any way

if you reject mails to "nore...@yourdomain.com" you will fail
sender-verify everywhere

You can reject emails but still allow the address to pass the VRFY
command, or better yet, just disable the VRFY command all-together which
has other benefits.


In postfix' case, "address verification" does not mean "use the SMTP 
VRFY command".
It means "send a specially-crafted, actual email message and record 
whether the recipient is accepted or not."


It is documented in detail here: 
http://www.postfix.org/ADDRESS_VERIFICATION_README.html


This will fail if, as previously mentioned, your MTA rejects a recipient 
address that was previously allowed to send mail.


Using VRFY is unreliable because there will be few MTAs in the wild that 
allow it anymore, due to its obvious spamability.




--
J.

Re: postfix devnull mailbox

[Reindl Harald]

On 21.12.2011 15:56, Viktor Dukhovni wrote:
> On Wed, Dec 21, 2011 at 04:35:14AM -0600, /dev/rob0 wrote:
> 
>>> if you reject mails to "nore...@yourdomain.com" you will fail
>>> sender-verify everywhere
>>
>> This is doable. [Most?] sender verify probes QUIT before DATA, so we 
>> can wait until DATA to reject.
> 
> The real solution is not misuse the "nore...@example.com" *header*
> address as an envelope sender address.
> 
> The envelope sender, especially for no-reply automatically generated
> email, must be a valid mailbox that is capable of receiving and
> acting on non-delivery reports (bounces).

have fun getting blacklisted by bounce mails to the noreply-address
which are spam using a spoofed sender of an existent person!



signature.asc
Description: OpenPGP digital signature

Re: postfix devnull mailbox

[Viktor Dukhovni]

On Wed, Dec 21, 2011 at 04:35:14AM -0600, /dev/rob0 wrote:

> > if you reject mails to "nore...@yourdomain.com" you will fail
> > sender-verify everywhere
> 
> This is doable. [Most?] sender verify probes QUIT before DATA, so we 
> can wait until DATA to reject.

The real solution is not misuse the "nore...@example.com" *header*
address as an envelope sender address.

The envelope sender, especially for no-reply automatically generated
email, must be a valid mailbox that is capable of receiving and
acting on non-delivery reports (bounces).

The "From:" header in such mail is not used for SAV probes, and
can and should be rejected by the MX hosts of the sending domain.

MAIL FROM:
RCPT TO:
DATA
From: Friendly Reminder 
To: Joe User 
Subject: There's a fire in the crowded theatre (noreply)

...

I've even in some cases created "noreply.example.com" sub-domains,
so that each sender gets a distinct "noreply" address, and the border
MX host rejects mail to the entire domain! Envelope sender addresses
in these "noreply" sub-domains are not allowed to leave, enforcing
proper envelope/header separation for this type of mail.

-- 
Viktor.

Re: postfix devnull mailbox

[Stan Hoeppner]

On 12/20/2011 9:19 PM, Peter wrote:

> In the case of SPAM the best solution is to deliver the email to
> the user's SPAM folder 

You must have an unlimited SAN hardware budget for your 1,000,000
mailbox site, if you practice what you preach above.  Potential FPs
should be routed to a "spam" folder, if you like.  Everything else
should be rejected or discarded.

The world is shades of grey Peter, not black and white.  SMTP RFCs even
have grey areas Peter.  I believe they are worded as "may" instead of
"should".

-- 
Stan

Re: postfix devnull mailbox

[/dev/rob0]

On Tuesday 20 December 2011 20:19:38 Reindl Harald wrote:
> Am 21.12.2011 01:29, schrieb Peter:
> > On 21/12/11 13:21, Reindl Harald wrote:
> >> so why does he not use the reply-button and what is he thinking
> >> does "nore...@mail.tld" mean? if you do not read the
> >> noreply-address it is the same as drop the messages, the only
> >> difference is on the storage
> > 
> > I am not excusing the sender's actions, I am simply stating that
> > if you are going to accept an email for delivery then you should
> > deliver it, to do otherwise gives a false impression to the
> > sender.
> 
> but this is not solveable in any way
> 
> if you reject mails to "nore...@yourdomain.com" you will fail
> sender-verify everywhere

This is doable. [Most?] sender verify probes QUIT before DATA, so we 
can wait until DATA to reject.

First, create the user or alias "nore...@example.com" such that it is 
valid in its address class.

Second, /path/to/noreply-reject:
nore...@example.com REJECT No replies to nore...@example.com

including other entries as needed, and 'postmap /path/to/noreply-
reject'.

Finally, main.cf:
smtpd_data_restrictions = [ ... ]
check_recipient_access hash:/path/to/noreply-reject
-- 
Offlist mail to this address is discarded unless
"/dev/rob0" or "not-spam" is in Subject: header

Re: postfix devnull mailbox

[Peter]

On 21/12/11 15:19, Reindl Harald wrote:
> 
> 
> Am 21.12.2011 01:29, schrieb Peter:
>> On 21/12/11 13:21, Reindl Harald wrote:
>>> so why does he not use the reply-button and what is he thinking does
>>> "nore...@mail.tld" mean? if you do not read the noreply-address it
>>> is the same as drop the messages, the only difference is on the storage
>>
>> I am not excusing the sender's actions, I am simply stating that if you
>> are going to accept an email for delivery then you should deliver it, to
>> do otherwise gives a false impression to the sender.
> 
> but this is not solveable in any way
> 
> if you reject mails to "nore...@yourdomain.com" you will fail
> sender-verify everywhere

You can reject emails but still allow the address to pass the VRFY
command, or better yet, just disable the VRFY command all-together which
has other benefits.


Peter

Re: postfix devnull mailbox

[Peter]

On 21/12/11 16:01, Stan Hoeppner wrote:
> The act of delivery to a mailbox does not guarantee the message will be
> read by a human, nor replied to, ever.  Thus there is zero practical
> difference, from the sender's POV, in this case, between delivering to
> /dev/null and to a mailbox whose contents are never read, but deleted
> each night via a cron job.  As someone else stated, the only difference
> is disk space usage.

Note that I never said that the only solution is to deliver the email.
What I said was that if the email is accepted for delivery it should be
delivered.  In this case the email should be rejected.

> To further shoot your argument down, many postqueue Spamassassin
> implementations at the MDA level discard spam before final delivery
> millions of times a day around the world.  Using your definitions, doing
> this is illegal/wrong as well.

Yes, this is wrong, just because a lot of people configure SA to drop
email does not make the practice correct.

There is one case where I will drop email and that is if it contains a
virus.  In the case of SPAM the best solution is to deliver the email to
the user's SPAM folder (that is if it didn't get rejected by postscreen
already).

> Yes, in a perfect world it's best to reject any mail at smtpd which you
> know you will not deliver.  But we don't live in a perfect world.  Thus,
> now and then, 'imperfect' solutions must be used for certain
> classes/types of problems.

Yes in a perfect world everyone would follow RFCs and do the right thing
with email.  Just because the world is not perfect is not an excuse for
you to make it worse.


Peter

Re: postfix devnull mailbox

[Stan Hoeppner]

On 12/20/2011 6:29 PM, Peter wrote:
> On 21/12/11 13:21, Reindl Harald wrote:
>> so why does he not use the reply-button and what is he thinking does
>> "nore...@mail.tld" mean? if you do not read the noreply-address it
>> is the same as drop the messages, the only difference is on the storage
> 
> I am not excusing the sender's actions, I am simply stating that if you
> are going to accept an email for delivery then you should deliver it, to
> do otherwise gives a false impression to the sender.

The act of delivery to a mailbox does not guarantee the message will be
read by a human, nor replied to, ever.  Thus there is zero practical
difference, from the sender's POV, in this case, between delivering to
/dev/null and to a mailbox whose contents are never read, but deleted
each night via a cron job.  As someone else stated, the only difference
is disk space usage.

To further shoot your argument down, many postqueue Spamassassin
implementations at the MDA level discard spam before final delivery
millions of times a day around the world.  Using your definitions, doing
this is illegal/wrong as well.

Yes, in a perfect world it's best to reject any mail at smtpd which you
know you will not deliver.  But we don't live in a perfect world.  Thus,
now and then, 'imperfect' solutions must be used for certain
classes/types of problems.

-- 
Stan

Re: postfix devnull mailbox

[Reindl Harald]

Am 21.12.2011 01:29, schrieb Peter:
> On 21/12/11 13:21, Reindl Harald wrote:
>> so why does he not use the reply-button and what is he thinking does
>> "nore...@mail.tld" mean? if you do not read the noreply-address it
>> is the same as drop the messages, the only difference is on the storage
> 
> I am not excusing the sender's actions, I am simply stating that if you
> are going to accept an email for delivery then you should deliver it, to
> do otherwise gives a false impression to the sender.

but this is not solveable in any way

if you reject mails to "nore...@yourdomain.com" you will fail
sender-verify everywhere



signature.asc
Description: OpenPGP digital signature

Re: postfix devnull mailbox

[Peter]

On 21/12/11 13:21, Reindl Harald wrote:
> so why does he not use the reply-button and what is he thinking does
> "nore...@mail.tld" mean? if you do not read the noreply-address it
> is the same as drop the messages, the only difference is on the storage

I am not excusing the sender's actions, I am simply stating that if you
are going to accept an email for delivery then you should deliver it, to
do otherwise gives a false impression to the sender.


Peter

Re: postfix devnull mailbox

[Reindl Harald]

Am 21.12.2011 00:47, schrieb Peter:
> On 21/12/11 10:11, Dennis Carr wrote:
>> In all seriousness, I guess it depends on who you ask.  For the original
>> poster's case, it's going to a "noreply" address, and I've seen cases
>> where nore...@foo.bar is simply eaten, more often than not, rather than
>> rejected. Besides, as far as I'm concerned, it does serve as an extra
>> use: messages to noreply or similar black hole addresses can serve as a
>> receptacle for flames.  Some yutz can decide he's going to e a jerk and
>> flame somebody that doesn't actually exist - s/he feels good about
>> {him,her}self in theory,
> 
> ...which is exactly why you should never drop email like that.  You are
> advocating for tricking a sender into thinking that his email was
> received when it was not.  The number of times of your scenario is going
> to be far outweighed by the number of emails that contain important
> information.  Even in your case it is likely that the ranting sender
> wants to be removed from your mailing list and to make him think you've
> received this email but not removed him from the list turns you into a
> spammer.

so why does he not use the reply-button and what is he thinking does
"nore...@mail.tld" mean? if you do not read the noreply-address it
is the same as drop the messages, the only difference is on the storage



signature.asc
Description: OpenPGP digital signature

Re: postfix devnull mailbox

[Peter]

On 21/12/11 10:11, Dennis Carr wrote:
> In all seriousness, I guess it depends on who you ask.  For the original
> poster's case, it's going to a "noreply" address, and I've seen cases
> where nore...@foo.bar is simply eaten, more often than not, rather than
> rejected. Besides, as far as I'm concerned, it does serve as an extra
> use: messages to noreply or similar black hole addresses can serve as a
> receptacle for flames.  Some yutz can decide he's going to e a jerk and
> flame somebody that doesn't actually exist - s/he feels good about
> {him,her}self in theory,

...which is exactly why you should never drop email like that.  You are
advocating for tricking a sender into thinking that his email was
received when it was not.  The number of times of your scenario is going
to be far outweighed by the number of emails that contain important
information.  Even in your case it is likely that the ranting sender
wants to be removed from your mailing list and to make him think you've
received this email but not removed him from the list turns you into a
spammer.

There is very rarely a good reason to drop email.


Peter

Re: postfix devnull mailbox

[Dennis Carr]

On Tue, 20 Dec 2011, /dev/rob0 wrote:


Why do you want to do that? What would be wrong with
rejecting that address?


/dev/null is just the proper repository to recycle bits. We don't want to 
run out. =^_^=


In all seriousness, I guess it depends on who you ask.  For the original 
poster's case, it's going to a "noreply" address, and I've seen cases 
where nore...@foo.bar is simply eaten, more often than not, rather than 
rejected. Besides, as far as I'm concerned, it does serve as an extra use: 
messages to noreply or similar black hole addresses can serve as a 
receptacle for flames.  Some yutz can decide he's going to e a jerk and 
flame somebody that doesn't actually exist - s/he feels good about 
{him,her}self in theory, and the only thing tat sees the message is 
postfix, which just relegates it to nothingness - leaving it to tie up 
storage resources only for as long as it takes for Postfix to chew on it.


 -Dennis
(who couldn't resist a bit if silliness and bounces null@ and some other 
addresses to /dev/null himself)

Re: postfix devnull mailbox

[/dev/rob0]

On Tuesday 20 December 2011 12:35:40 Roberto Greiner wrote:
> I'm trying to create a /dev/null mailbox, but didn't get much
> success following the recipe at
> http://www.serverwatch.com/columns/article.php/3844371/Forwarding-a
> -Postfix-Virtual-Alias-to-devnull.htm
> 
> What I did was following:
> - Add a "blackhole" alias in /etc/aliases (blackhole: /dev/null),
> an ran "newaliases" to validate it.

Okay so far, except that the concept of discarding mail is generally 
not a good idea. Why do you want to do that? What would be wrong with 
rejecting that address?

That said, as P@rick points out, we do have a discard(8) delivery 
agent which can be directed to using transport(5) maps.

http://www.postfix.org/transport.5.html
http://www.postfix.org/discard.8.html
http://www.postfix.org/postconf.5.html#transport_maps

> - Added the following in mysql_virtual_alias_maps.cf:
>no-reply@ = blackhole

This sounds wrong. Furthermore, it is not a good idea to use a bare 
username in place of a full email address. You should have used 
"blackh...@some.domain.listed.in.mydestination".

See virtual(5) for the format of virtual_alias_maps lookup keys and 
results. See mysql_table(5) for the details of setting up a query in 
Postfix. See MySQL documentation for information about setting up a 
database in mysql.

http://www.postfix.org/virtual.5.html
http://www.postfix.org/mysql_table.5.html
http://www.mysql.com/

> - Ran:
>postmap /usr/local/etc/postfix/mysql_virtual_alias_maps.cf (it's

You do not compile a query file with postmap. But, you can use postmap 
to test your lookups.

http://www.postfix.org/postmap.1.html

> a FreeBSD platform)
> - Restarted Postfix.

Not necessary.

> Sending an email to no-reply@ got me the following error
> message in /var/log/maillog:
> NOQUEUE: reject: RCPT from unknown[]: 450 4.1.1
> >: Recipient address rejected: User unknown in
> virtual mailbox table; from=<> to= domain>> proto=ESMTP helo=<[]>

The munged-out domain is in virtual_mailbox_domains, but the address 
no-reply@ is not listed in virtual_mailbox_maps.

> I tried adding the same entry from mysql_virtual_alias_maps.cf into
> mysql_virtual_mailbox_maps.cf, but no success either. Also, just in

Those sound like they are database queries, not actual map files.

> case, the same page above mentions that adding a valid user for the
> aliases might be necessary. Didn't help either.
> 
> Any ideas would be welcome.

If this doesn't help, http://www.postfix.org/DEBUG_README.html#mail 
tells you how to post here such that you can get more useful answers. 
Also, it might be difficult to figure out a mail routing issue where 
you have munged the domains.

> PS: My setup is the following:
> FreeBSD 7.2 machine
> Postfix 2.8.2
> Postfixadmin 2.3.2
> 
> 
> main.cf has at the end the following entries:
> ## MySQL access
> virtual_alias_maps =
> mysql:/usr/local/etc/postfix/mysql_virtual_alias_maps.cf

Yup, if this is right, it's a query file.

> virtual_gid_maps = static:125
> virtual_mailbox_base = /var/mail
> virtual_mailbox_domains =
> mysql:/usr/local/etc/postfix/mysql_virtual_domains_maps.cf
> virtual_mailbox_limit = 104857600
> virtual_mailbox_maps =
> mysql:/usr/local/etc/postfix/mysql_virtual_mailbox_maps.cf
> virtual_minimum_uid = 125
> virtual_transport = virtual
> #virtual_transport = maildrop
> virtual_uid_maps = static:125
> # Additional for quota support
> virtual_create_maildirsize = yes
> virtual_mailbox_extended = yes
> virtual_mailbox_limit_maps =
> mysql:/usr/local/etc/postfix/mysql_virtual_mailbox_limit_maps.cf
> virtual_mailbox_limit_override = yes
> virtual_maildir_limit_message = Desculpe, tamanho da caixa postal
> excedido, tente mais tarde! Sorry, mailbox size exceeded, try
> later!
> virtual_overquota_bounce = yes
-- 
Offlist mail to this address is discarded unless
"/dev/rob0" or "not-spam" is in Subject: header

Re: postfix devnull mailbox

[Patrick Ben Koetter]

* Roberto Greiner :
> I'm trying to create a /dev/null mailbox, but didn't get much
> success following the recipe at 
> http://www.serverwatch.com/columns/article.php/3844371/Forwarding-a-Postfix-Virtual-Alias-to-devnull.htm
> 
> What I did was following:
> - Add a "blackhole" alias in /etc/aliases (blackhole: /dev/null), an
> ran "newaliases" to validate it.
> - Added the following in mysql_virtual_alias_maps.cf:
>   no-reply@ = blackhole
> - Ran:
>   postmap /usr/local/etc/postfix/mysql_virtual_alias_maps.cf (it's a
> FreeBSD platform)
> - Restarted Postfix.

send messages to the discard service.

p@rick



> 
> Sending an email to no-reply@ got me the following error
> message in /var/log/maillog:
> NOQUEUE: reject: RCPT from unknown[]: 450 4.1.1
> >: Recipient address rejected: User unknown in
> virtual mailbox table; from=<> to= domain>> proto=ESMTP helo=<[]>
> 
> I tried adding the same entry from mysql_virtual_alias_maps.cf into
> mysql_virtual_mailbox_maps.cf, but no success either. Also, just in
> case, the same page above mentions that adding a valid user for the
> aliases might be necessary. Didn't help either.
> 
> Any ideas would be welcome.
> 
> Thanks
> 
> Roberto
> 
> PS: My setup is the following:
> FreeBSD 7.2 machine
> Postfix 2.8.2
> Postfixadmin 2.3.2
> 
> 
> main.cf has at the end the following entries:
> ## MySQL access
> virtual_alias_maps =
> mysql:/usr/local/etc/postfix/mysql_virtual_alias_maps.cf
> virtual_gid_maps = static:125
> virtual_mailbox_base = /var/mail
> virtual_mailbox_domains =
> mysql:/usr/local/etc/postfix/mysql_virtual_domains_maps.cf
> virtual_mailbox_limit = 104857600
> virtual_mailbox_maps =
> mysql:/usr/local/etc/postfix/mysql_virtual_mailbox_maps.cf
> virtual_minimum_uid = 125
> virtual_transport = virtual
> #virtual_transport = maildrop
> virtual_uid_maps = static:125
> # Additional for quota support
> virtual_create_maildirsize = yes
> virtual_mailbox_extended = yes
> virtual_mailbox_limit_maps =
> mysql:/usr/local/etc/postfix/mysql_virtual_mailbox_limit_maps.cf
> virtual_mailbox_limit_override = yes
> virtual_maildir_limit_message = Desculpe, tamanho da caixa postal
> excedido, tente mais tarde! Sorry, mailbox size exceeded, try later!
> virtual_overquota_bounce = yes
> 
> 
> -- 
>   -
> Marcos Roberto Greiner
> 
>Os otimistas acham que estamos no melhor dos mundos
> Os pessimistas tem medo de que isto seja verdade
>   James Branch Cabell
>   -
> 

-- 
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):

postfix devnull mailbox

[Roberto Greiner]

Hi,

I'm trying to create a /dev/null mailbox, but didn't get much success 
following the recipe at 
http://www.serverwatch.com/columns/article.php/3844371/Forwarding-a-Postfix-Virtual-Alias-to-devnull.htm


What I did was following:
- Add a "blackhole" alias in /etc/aliases (blackhole: /dev/null), an ran 
"newaliases" to validate it.

- Added the following in mysql_virtual_alias_maps.cf:
  no-reply@ = blackhole
- Ran:
  postmap /usr/local/etc/postfix/mysql_virtual_alias_maps.cf (it's a 
FreeBSD platform)

- Restarted Postfix.

Sending an email to no-reply@ got me the following error 
message in /var/log/maillog:
NOQUEUE: reject: RCPT from unknown[]: 450 4.1.1 
>: Recipient address rejected: User unknown in 
virtual mailbox table; from=<> to=domain>> proto=ESMTP helo=<[]>


I tried adding the same entry from mysql_virtual_alias_maps.cf into 
mysql_virtual_mailbox_maps.cf, but no success either. Also, just in 
case, the same page above mentions that adding a valid user for the 
aliases might be necessary. Didn't help either.


Any ideas would be welcome.

Thanks

Roberto

PS: My setup is the following:
FreeBSD 7.2 machine
Postfix 2.8.2
Postfixadmin 2.3.2


main.cf has at the end the following entries:
## MySQL access
virtual_alias_maps = 
mysql:/usr/local/etc/postfix/mysql_virtual_alias_maps.cf

virtual_gid_maps = static:125
virtual_mailbox_base = /var/mail
virtual_mailbox_domains = 
mysql:/usr/local/etc/postfix/mysql_virtual_domains_maps.cf

virtual_mailbox_limit = 104857600
virtual_mailbox_maps = 
mysql:/usr/local/etc/postfix/mysql_virtual_mailbox_maps.cf

virtual_minimum_uid = 125
virtual_transport = virtual
#virtual_transport = maildrop
virtual_uid_maps = static:125
# Additional for quota support
virtual_create_maildirsize = yes
virtual_mailbox_extended = yes
virtual_mailbox_limit_maps = 
mysql:/usr/local/etc/postfix/mysql_virtual_mailbox_limit_maps.cf

virtual_mailbox_limit_override = yes
virtual_maildir_limit_message = Desculpe, tamanho da caixa postal 
excedido, tente mais tarde! Sorry, mailbox size exceeded, try later!

virtual_overquota_bounce = yes


--
  -
Marcos Roberto Greiner

   Os otimistas acham que estamos no melhor dos mundos
Os pessimistas tem medo de que isto seja verdade
  James Branch Cabell
  -