Re: Virtual Aliases Usage and Syntax Question

[LuKreme]

On Sep 27, 2009, at 0:53, Erick Calder  wrote:

 if the message were for no-ex...@arix.com then it gets rerouted to n...@arix.com 
 which also doesn't exist and therefor bounces.


Yes, it bounces. This makes you a backacatter source. This is bad.

Re: Virtual Aliases Usage and Syntax Question

[Erick Calder]

On Sep 27, 2009, at 12:53 AM, LuKreme wrote:


On Sep 27, 2009, at 0:53, Erick Calder  wrote:

 if the message were for no-ex...@arix.com then it gets rerouted to n...@arix.com 
 which also doesn't exist and therefor bounces.


Yes, it bounces. This makes you a backacatter source. This is bad.


but doesn't my postfix server bounce by default when receiving a mail  
for an inexistent address? and if it doesn't, how are users who  
misspell my address to know their message didn't get delivered?

Re: Virtual Aliases Usage and Syntax Question

[mouss]

Erick Calder wrote:
> On Sep 27, 2009, at 12:53 AM, LuKreme wrote:
> 
>> On Sep 27, 2009, at 0:53, Erick Calder > > wrote:
>>
>>>  if the message were for no-ex...@arix.com
>>>  then it gets rerouted to
>>> n...@arix.com  which also
>>> doesn't exist and therefor bounces.
>>
>> Yes, it bounces. This makes you a backacatter source. This is bad. 
> 
> but doesn't my postfix server bounce by default when receiving a mail
> for an inexistent address? and if it doesn't, how are users who misspell
> my address to know their message didn't get delivered?

postfix doesn't bounce when it rejects mail to invalid recipients. it is
the sending MTA which generates the bounce.

as already suggested, put the user part in the expression, or use sql. I
have already posted an example, so I won't repeat it here.

Re: Virtual Aliases Usage and Syntax Question

[Ansgar Wiechers]

On 2009-09-27 Erick Calder wrote:
> On Sep 27, 2009, at 12:53 AM, LuKreme wrote:
>> On Sep 27, 2009, at 0:53, Erick Calder  wrote:
>>> if the message were for no-ex...@arix.com then it gets rerouted to 
>>> n...@arix.com which also doesn't exist and therefor bounces.
>>
>> Yes, it bounces. This makes you a backacatter source. This is bad.
>
> but doesn't my postfix server bounce by default when receiving a mail for 
> an inexistent address?

No. In that case it rejects the mail¹, meaning that the response goes
back to the sending MTA instead of going to the address given in the
envelope from (which is usually forged in case of spam mails).

Regards
Ansgar Wiechers

¹ At least that's what it *should* do, unless you configured it to
  accept all mail first, and check later whether it can actually deliver
  it.
-- 
"All vulnerabilities deserve a public fear period prior to patches
becoming available."
--Jason Coombs on Bugtraq

Re: Virtual Aliases Usage and Syntax Question

[mouss]

Erick Calder wrote:
> haha, clearly my regex is borked.  I tried replying and got the mail
> back with:
> 
> This Message was undeliverable due to the following reason:
> 
> Each of the following recipients was rejected by a remote mail server.
> The reasons given by the server are included to help you determine why
> each recipient was rejected.
> 
>Recipient: mailto:postfix+us...@postfix.org>>
>Reason:5.1.1  >: Recipient address rejected: User
> unknown in virtual alias table
> 


you are rewriting all addresses in the universe. do not touch addresses
that are not yours.

Start from the example I already sent:

== virtual_alias_maps:

/^(joe|jim|jane)-(.*)@(example\.net|example\.com)$/$1...@$3

slightly OT: size data

[Stan Hoeppner]

Hi all,

Until a day or two ago I'd never seen this in my pflogsumm output:

Messages with no size data
--

 03B593DA160  redac...@hardwarefreak.com
 0E4283DA160  redac...@hardwarefreak.com
 118663DA160  redac...@hardwarefreak.com
 1D5973DA160  redac...@hardwarefreak.com
 1EDF13DA160  redac...@hardwarefreak.com
 25BE03DA160  redac...@hardwarefreak.com
 296B53DA160  redac...@hardwarefreak.com
 2B3F83DA160  redac...@hardwarefreak.com
 2E79B3DA160  redac...@hardwarefreak.com

That's a sample.  There are about 30 of these from yesterday.  I grep'd
for the message IDs and most of them are from the postfix-users
cloud9.net servers.  That in and of itself doesn't mean much though
because a large % of my legit mail is from postfix-users.  One of these
'size-less' messages originated from my workstation and was relayed
outbound, and this _really_ piques my curiosity.  If all these size-less
messages came from the outside world, I'd not think much of this issue.
 I wouldn't think a message originated locally from my MUA would
suddenly have no size data, when this hasn't occurred in 4 years.  This
make me think something goofy is going on with my Postfix.

AFAIK, I've made no recent config changes in main.cf that might cause
this.  And I've never, ever touched master.cf.

Any ideas why I've run this same postfix box for over 4 years, and have
never seen missing size data reported in pflogsumm?  I haven't upgraded
pflogsumm either.  I'm still running the first/only version I ever
installed.  And I've not upgraded Postfix recently, still on
2.3.8/Debian/Etch for quite some time.

The only recent change I've made is the two DNS resolvers in my router
config (it proxies DNS requests for LAN hosts).  But, I think I made
this change _after_ I started noticing the 'missing size data' entries.

Obviously this isn't critical (I don't think).  I'm just baffled and
wondering what's causing this.  Weird...

--
Stan

Re: slightly OT: size data

[Wietse Venema]

If you have a question about POSTFIX logs, then it is a good idea
to send samples of POSTFIX logging.

Wietse

Re: slightly OT: size data

[Stan Hoeppner]

Wietse Venema put forth on 9/27/2009 7:39 AM:
> If you have a question about POSTFIX logs, then it is a good idea
> to send samples of POSTFIX logging.
> 
>   Wietse


Point taken, sry Wietse.   Upon grabbing these sample entries, I noticed
the transactions pflogsumm is flagging have no qmgr entries.  That
explains why pflogsumm is complaining there is no size data.  So, I
guess the question is, why did qmgr intermittently/randomly stop
stamping the log file, as of a day or two ago?

/../gcml.sh

#!/bin/sh
grep $1 /var/log/mail.log


greer:/home/stan# gcml 0602C3DA160
Sep 27 04:54:28 greer postfix/smtpd[25766]: 0602C3DA160:
client=camomile.cloud9.net[168.100.1.3]
Sep 27 04:54:28 greer postfix/cleanup[25769]: 0602C3DA160:
message-id=<20090927095400.4958d103...@camomile.cloud9.net>
Sep 27 04:54:28 greer postfix/smtp[25770]: 0602C3DA160:
to=, relay=192.168.100.2[192.168.100.2]:25,
delay=2.4, delays=2/0.03/0.13/0.28, dsn=2.0.0, status=sent (250 OK)

greer:/home/stan# gcml B8D863DA160
Sep 27 07:40:05 greer postfix/smtpd[26560]: B8D863DA160:
client=english-breakfast.cloud9.net[168.100.1.7]
Sep 27 07:40:05 greer postfix/cleanup[26563]: B8D863DA160:
message-id=<20090927123943.24a021f3...@spike.porcupine.org>
Sep 27 07:40:05 greer postfix/qmgr[26156]: B8D863DA160:
from=, size=3339, nrcpt=1 (queue active)
Sep 27 07:40:06 greer postfix/smtp[26564]: B8D863DA160:
to=, relay=192.168.100.2[192.168.100.2]:25,
delay=2, delays=1.5/0.03/0.17/0.35, dsn=2.0.0, status=sent (250 OK)
Sep 27 07:40:06 greer postfix/qmgr[26156]: B8D863DA160: removed

Re: slightly OT: size data

[Wietse Venema]

Stan Hoeppner:
> Wietse Venema put forth on 9/27/2009 7:39 AM:
> > If you have a question about POSTFIX logs, then it is a good idea
> > to send samples of POSTFIX logging.
> 
> Point taken, sry Wietse.   Upon grabbing these sample entries, I noticed
> the transactions pflogsumm is flagging have no qmgr entries.  That
> explains why pflogsumm is complaining there is no size data.  So, I
> guess the question is, why did qmgr intermittently/randomly stop
> stamping the log file, as of a day or two ago?

Apparently, your system runs daemons in a chroot environment that
does not contain the required syslog socket.

As shipped by me, Postfix does not run daemons in a chroot environment,
because the details vary with operating system and with system
version. If a maintainer or system administrator turns on the
Postfix chroot feature, then it is their responsibility to set
things up properly.

Wietse

Re: Virtual Aliases Usage and Syntax Question

[LuKreme]

On Sep 27, 2009, at 3:52, Erick Calder  wrote:

but doesn't my postfix server bounce by default when receiving a  
mail for an inexistent address?


No, not generally. Unknown users are REJECTed, not bounced.

Re: Virtual Aliases Usage and Syntax Question

[Erick Calder]

On Sep 27, 2009, at 1:03 PM, LuKreme wrote:


On Sep 27, 2009, at 2:52 AM, Erick Calder wrote:


On Sep 27, 2009, at 12:53 AM, LuKreme wrote:


On Sep 27, 2009, at 0:53, Erick Calder  wrote:

 if the message were for no-ex...@arix.com then it gets rerouted  
to n...@arix.com which also doesn't exist and therefor bounces.


Yes, it bounces. This makes you a backacatter source. This is bad.


but doesn't my postfix server bounce by default when receiving a  
mail for an inexistent address? and if it doesn't, how are users  
who misspell my address to know their message didn't get delivered?




No, not generally. Unknown users are REJECTed, not bounced.


ok, I'm not getting this.  your statements of 12:53AM and of 1:03PM  
seem contradictory... if an address doesn't exist, does it get bounced  
(as stated on 12:53AM) or rejected (as stated on 1:03PM, in which case  
I'm _not_ a backscatter source, and with which Ansgar and mouss seem  
to agree)?

Re: Virtual Aliases Usage and Syntax Question

[Erick Calder]

On Sep 25, 2009, at 7:12, Charles Marcus   
wrote:



On 9/24/2009, LuKreme (krem...@kreme.com) wrote:

virtual_alias_maps =
  hash:$config_directory/virtual
  pcre:$config_directory/virtual.pcre,
  pcre:$config_directory/virtual_sql.pcre,
  proxy:mysql:$config_directory/mysql_virtual_alias_maps.cf

The first line is local users, the last is the sql lookup for the SQL
users, and the two pcre's are dynamically created to convert
user_extension addresses to user+extension (not recommended).


Why not recommended? The only problem I could see is if the system
allowed valid usernames with an underscore, right?


Charles, why would allowing underscores in the username be a problem?   
I'm asking because quite curiously my use of /^e[._\/-...@arix.com$/ e+$...@arix.com 
 seems to work for all the characters in the set, _except_ for the  
underscore...

Re: Virtual Aliases Usage and Syntax Question

[Sahil Tandon]

On Sun, 27 Sep 2009, Erick Calder wrote:

> On Sep 27, 2009, at 1:03 PM, LuKreme wrote:
>
> >No, not generally. Unknown users are REJECTed, not bounced.
> 
> ok, I'm not getting this.  your statements of 12:53AM and of 1:03PM
> seem contradictory... if an address doesn't exist, does it get bounced
> (as stated on 12:53AM) or rejected (as stated on 1:03PM, in which case
> I'm _not_ a backscatter source, and with which Ansgar and mouss seem
> to agree)?

You're getting lost in the semantics.  Bottom line: unless you break it,
Postfix sends the SMTP client a 550 when an invalid/unknown recipient is
specified in RCPT TO.  If your virtual aliasing (by way of regex
rewriting) breaks recipient validation, *then* you are likely to
backscatter.

-- 
Sahil Tandon 

Re: Virtual Aliases Usage and Syntax Question

[Charles Marcus]

On 9/27/2009, Erick Calder (e...@arix.com) wrote:
>>> The first line is local users, the last is the sql lookup for the SQL
>>> users, and the two pcre's are dynamically created to convert
>>> user_extension addresses to user+extension (not recommended).

>> Why not recommended? The only problem I could see is if the system
>> allowed valid usernames with an underscore, right?

> Charles, why would allowing underscores in the username be a problem?

? Because doing so would break the intended behavior?

Remember, my comment was only in context with the underscore being used
as an additional (in addition to the '+' character) recipient delimeter.
At least, thats the context I thought I was replying to...

Re: Virtual Aliases Usage and Syntax Question

[Ansgar Wiechers]

On 2009-09-27 Erick Calder wrote:
> On Sep 27, 2009, at 1:03 PM, LuKreme wrote:
>> On Sep 27, 2009, at 2:52 AM, Erick Calder wrote:
>>> On Sep 27, 2009, at 12:53 AM, LuKreme wrote:
 On Sep 27, 2009, at 0:53, Erick Calder  wrote:
>  if the message were for no-ex...@arix.com then it gets rerouted  
> to n...@arix.com which also doesn't exist and therefor bounces.

 Yes, it bounces. This makes you a backacatter source. This is bad.
>>>
>>> but doesn't my postfix server bounce by default when receiving a mail 
>>> for an inexistent address? and if it doesn't, how are users who 
>>> misspell my address to know their message didn't get delivered?
>>
>> No, not generally. Unknown users are REJECTed, not bounced.
>
> ok, I'm not getting this.  your statements of 12:53AM and of 1:03PM
> seem contradictory... if an address doesn't exist, does it get bounced
> (as stated on 12:53AM) or rejected (as stated on 1:03PM, in which case
> I'm _not_ a backscatter source, and with which Ansgar and mouss seem
> to agree)?

You're just misunderstanding how virtual alias maps work.

During the SMTP dialog Postfix checks its various recipient/relay maps
for valid recipients. If a valid match is found, the mail is accepted
and queued for further relaying. However, Postfix does not expand the
virtual alias maps at this point. If you have a match on the left side
of your virtual aliases, Postfix does not check whether the
corresponding right side entry actually is valid.

Basically the process goes like this:

- Sending MTA starts SMTP dialog, giving no-ex...@arix.com as the RCPT
  TO address
- Postfix finds mapping no-ex...@arix.com -> n...@arix.com in its virtual
  alias maps
- Postfix accepts the mail and queues it for further delivery, because a
  valid mapping exists
- Next Postfix tries to relay the already accepted mail to n...@arix.com,
  which is rejected, becaus n...@arix.com doesn't exist
- Postfix thus finds itself unable to deliver the mail accepted for
  no-ex...@arix.com, and thus (as per RFC 2821) MUST generate a bounce

That's why you want to accept mail only for valid addresses.

Regards
Ansgar Wiechers
-- 
"Abstractions save us time working, but they don't save us time learning."
--Joel Spolsky

Re: Virtual Aliases Usage and Syntax Question

[Erick Calder]

thank you guys for taking the time to explain things.  I see why it's  
an issue.


On Sep 27, 2009, at 3:51 PM, Ansgar Wiechers wrote:


On 2009-09-27 Erick Calder wrote:

On Sep 27, 2009, at 1:03 PM, LuKreme wrote:

On Sep 27, 2009, at 2:52 AM, Erick Calder wrote:

On Sep 27, 2009, at 12:53 AM, LuKreme wrote:

On Sep 27, 2009, at 0:53, Erick Calder  wrote:

if the message were for no-ex...@arix.com then it gets rerouted
to n...@arix.com which also doesn't exist and therefor bounces.


Yes, it bounces. This makes you a backacatter source. This is bad.


but doesn't my postfix server bounce by default when receiving a  
mail

for an inexistent address? and if it doesn't, how are users who
misspell my address to know their message didn't get delivered?


No, not generally. Unknown users are REJECTed, not bounced.


ok, I'm not getting this.  your statements of 12:53AM and of 1:03PM
seem contradictory... if an address doesn't exist, does it get  
bounced
(as stated on 12:53AM) or rejected (as stated on 1:03PM, in which  
case

I'm _not_ a backscatter source, and with which Ansgar and mouss seem
to agree)?


You're just misunderstanding how virtual alias maps work.

During the SMTP dialog Postfix checks its various recipient/relay maps
for valid recipients. If a valid match is found, the mail is accepted
and queued for further relaying. However, Postfix does not expand the
virtual alias maps at this point. If you have a match on the left side
of your virtual aliases, Postfix does not check whether the
corresponding right side entry actually is valid.

Basically the process goes like this:

- Sending MTA starts SMTP dialog, giving no-ex...@arix.com as the RCPT
 TO address
- Postfix finds mapping no-ex...@arix.com -> n...@arix.com in its  
virtual

 alias maps
- Postfix accepts the mail and queues it for further delivery,  
because a

 valid mapping exists
- Next Postfix tries to relay the already accepted mail to  
n...@arix.com,

 which is rejected, becaus n...@arix.com doesn't exist
- Postfix thus finds itself unable to deliver the mail accepted for
 no-ex...@arix.com, and thus (as per RFC 2821) MUST generate a bounce

That's why you want to accept mail only for valid addresses.

Regards
Ansgar Wiechers
--
"Abstractions save us time working, but they don't save us time  
learning."

--Joel Spolsky

SPF FAILURES

[Homer Wilson Smith]

 Dear Sirs,

 Running Fedora Core 3, postfix 2.1.5, spf 2.007

 Remote customer an...@thumpernet.com sends e-mail to
ho...@lightlink.com via our incoming mail server at smtp0.lightlink.com
which is running the above mentioned software.

 dig thumpernet.com mx shows mail.thumpernet.com at 71.176.110.29
which is correct.

 dig thumpernet.com txt shows "v=spf1 mx -all" which is also
correct.

 Yet mail from his mx to our mail server is refused by the spf code
as shown below.  The web page at openspf says "we got no clue why".

Any help would be appreciated, thanks in advance to all.

main.cf and master.cf posted below.

Homer


Sep 27 14:16:57 smtp0 postfix/smtpd[2465]: connect from 
mail.thumpernet.com[71.176.110.29]
Sep 27 14:16:58 smtp0 postgrey[6718]: action=pass, reason=client AWL, client_name=mail.thumpernet.com, client_address=71.176.110.29, sender=an...@thumpernet.com, recipient=ho...@lightlink.com 
Sep 27 14:16:58 smtp0 postfix/policy-spf[2492]: Attribute: client_name=mail.thumpernet.com 
Sep 27 14:16:58 smtp0 postfix/policy-spf[2492]: Attribute: helo_name=mail.thumpernet.com 
Sep 27 14:16:58 smtp0 postfix/policy-spf[2492]: Attribute: sender=an...@thumpernet.com 
Sep 27 14:16:58 smtp0 postfix/policy-spf[2492]: : SPF fail (Mechanism '-all' matched): HELO/EHLO: mail.thumpernet.com, IP Address: 71.176.110.29, Recipient: ho...@lightlink.com 
Sep 27 14:16:58 smtp0 postfix/policy-spf[2492]: : SPF fail (Mechanism '-all' matched): HELO/EHLO: mail.thumpernet.com 
Sep 27 14:16:58 smtp0 postfix/policy-spf[2492]: handler sender_policy_framework: 550 Please see http://www.openspf.org/Why?s=helo;id=mail.thumpernet.com;ip=71.176.110.29;r=smtp0.lightlink.com 
Sep 27 14:16:58 smtp0 postfix/policy-spf[2492]: : Policy action=550 Please see http://www.openspf.org/Why?s=helo;id=mail.thumpernet.com;ip=71.176.110.29;r=smtp0.lightlink.com 
Sep 27 14:16:58 smtp0 postfix/smtpd[2465]: NOQUEUE: reject: RCPT from mail.thumpernet.com[71.176.110.29]: 550 : Recipient address rejected: Please see http://www.openspf.org/Why?s=helo;id=mail.thumpernet.com;ip=71.176.110.29;r=smtp0.lightlink.com; from= to= proto=ESMTP helo=

Sep 27 14:16:58 smtp0 postfix/smtpd[2465]: disconnect from 
mail.thumpernet.com[71.176.110.29]


/etc/postfix/main.cf
smtpd_client_connection_count_limit = 1
default_destination_concurrency_limit = 1
transport_maps = hash:/etc/postfix/transport
bounce_queue_lifetime = 10d
recipient_delimiter = +
smtpd_hard_error_limit = 3
smtpd_soft_error_limit = 3
default_process_limit = 200
smtpd_helo_required = yes
smtpd_client_restrictions=
   reject_rbl_client bl.spamcop.net
   reject_rbl_client zen.spamhaus.org 
smtpd_sender_restrictions = reject_unknown_sender_domain

smtpd_recipient_restrictions =
   permit_mynetworks
   reject_unauth_destination
   check_policy_service inet:127.0.0.1:10023
#   check_policy_service unix:private/policy
policy_time_limit = 3600

message_size_limit=1
mailbox_size_limit=20

# Global Postfix configuration file. This file lists only a subset
# of all 300+ parameters. See the postconf(5) manual page for a
# complete list.
#
# The general format of each line is: parameter = value. Lines
# that begin with whitespace continue the previous line. A value can
# contain references to other $names or ${name}s.
#
# NOTE - CHANGE NO MORE THAN 2-3 PARAMETERS AT A TIME, AND TEST IF
# POSTFIX STILL WORKS AFTER EVERY CHANGE.

# SOFT BOUNCE
#
# The soft_bounce parameter provides a limited safety net for
# testing.  When soft_bounce is enabled, mail will remain queued that
# would otherwise bounce. This parameter disables locally-generated
# bounces, and prevents the SMTP server from rejecting mail permanently
# (by changing 5xx replies into 4xx replies). However, soft_bounce
# is no cure for address rewriting mistakes or mail routing mistakes.
#
soft_bounce = no

# LOCAL PATHNAME INFORMATION
#
# The queue_directory specifies the location of the Postfix queue.
# This is also the root directory of Postfix daemons that run chrooted.
# See the files in examples/chroot-setup for setting up Postfix chroot
# environments on different UNIX systems.
#
queue_directory = /var/spool/postfix

# The command_directory parameter specifies the location of all
# postXXX commands.
#
command_directory = /usr/sbin

# The daemon_directory parameter specifies the location of all Postfix
# daemon programs (i.e. programs listed in the master.cf file). This
# directory must be owned by root.
#
daemon_directory = /usr/libexec/postfix

# QUEUE AND PROCESS OWNERSHIP
#
# The mail_owner parameter specifies the owner of the Postfix queue
# and of most Postfix daemon processes.  Specify the name of a user
# account THAT DOES NOT SHARE ITS USER OR GROUP ID WITH OTHER ACCOUNTS
# AND THAT OWNS NO OTHER FILES OR PROCESSES ON THE SYSTEM.  In
# particular, don't specify nobody or daemon. PLEASE USE A DEDICATED
# USER.
#
mail_owner = postfix

# The default_privs parameter specifies the default rights

Re: SPF FAILURES

[Sahil Tandon]

On Sun, 27 Sep 2009, Homer Wilson Smith wrote:

> Running Fedora Core 3, postfix 2.1.5, spf 2.007

You should upgrade Postfix.

> Remote customer an...@thumpernet.com sends e-mail to
> ho...@lightlink.com via our incoming mail server at
> smtp0.lightlink.com which is running the above mentioned software.
> 
> dig thumpernet.com mx shows mail.thumpernet.com at 71.176.110.29 which
> is correct.
> 
> dig thumpernet.com txt shows "v=spf1 mx -all" which is also correct.
> 
> Yet mail from his mx to our mail server is refused by the spf code as
> shown below.  The web page at openspf says "we got no clue why".

This has nothing to do with Postfix.

> Any help would be appreciated, thanks in advance to all.

Seek help on the appropriate mailing list.

> main.cf and master.cf posted below.

In the future, when you *do* have a Postfix problem, never paste the
contents of main.cf; instead, show the output of 'postconf -n'.  Please
also read the DEBUG_README (it is a document to which you were linked
upon joining this mailing list).

> 27 14:16:58 smtp0 postfix/policy-spf[2492]: Attribute:
> sender=an...@thumpernet.com Sep 27 14:16:58 smtp0
> postfix/policy-spf[2492]: : SPF fail (Mechanism '-all' matched):
> HELO/EHLO: mail.thumpernet.com, IP Address: 71.176.110.29, Recipient:
> ho...@lightlink.com Sep 27 14:16:58 smtp0 postfix/policy-spf[2492]: :
> SPF fail (Mechanism '-all' matched): HELO/EHLO: mail.thumpernet.com
> Sep 27 14:16:58 smtp0 postfix/policy-spf[2492]: handler
> sender_policy_framework: 550 Please see
> http://www.openspf.org/Why?s=helo;id=mail.thumpernet.com;ip=71.176.110.29;r=smtp0.lightlink.com
> Sep 27 14:16:58 smtp0 postfix/policy-spf[2492]: : Policy action=550
> Please see
> http://www.openspf.org/Why?s=helo;id=mail.thumpernet.com;ip=71.176.110.29;r=smtp0.lightlink.com
> Sep 27 14:16:58 smtp0 postfix/smtpd[2465]: NOQUEUE: reject: RCPT from
> mail.thumpernet.com[71.176.110.29]: 550 :
> Recipient address rejected: Please see
> http://www.openspf.org/Why?s=helo;id=mail.thumpernet.com;ip=71.176.110.29;r=smtp0.lightlink.com;
> from= to= proto=ESMTP
> helo= Sep 27 14:16:58 smtp0 postfix/smtpd[2465]:
> disconnect from mail.thumpernet.com[71.176.110.29]

-- 
Sahil Tandon 

Re: SPF FAILURES

[Michael Orlitzky]

Homer Wilson Smith wrote:


 dig thumpernet.com mx shows mail.thumpernet.com at 71.176.110.29
which is correct.

 dig thumpernet.com txt shows "v=spf1 mx -all" which is also
correct.

...

>
SPF fail (Mechanism '-all' matched): HELO/EHLO: mail.thumpernet.com Sep 
27 14:16:58 smtp0 postfix/policy-spf[2492]: handler 
sender_policy_framework: 550 Please see 
http://www.openspf.org/Why?s=helo;id=mail.thumpernet.com;ip=71.176.110.29;r=smtp0.lightlink.com 
Sep 27 14:16:58 smtp0 postfix/policy-spf[2492]: : Policy action=550 


They are failing SPF on the HELO/EHLO hostname. They are correctly 
announcing themselves as mail.thumpernet.com. However, they have defined 
an SPF record for this hostname:


  $ dig +short mail.thumpernet.com txt
  "v=spf1 mx -all"

which essentially states "allow the MX for mail.thumpernet.com to send 
mail from mail.thumpernet.com." Problem is, there's no MX for 
mail.thumpernet.com:


  $ dig +short mail.thumpernet.com mx
  

In other words, they have incorrectly assumed that the "mx" mechanism 
would always refer to the domain name, rather than the host for which 
the SPF record is defined. See,


  http://www.openspf.org/FAQ/Common_mistakes

for more info. In particular, check the section titled, "Publish SPF 
records for HELO names used by your mail servers." If you have any other 
questions, please ask them on an SPF list.

Strange lack of SMTP rejections

[Russell Jones]

For some reason, if a local user sends mail to another local user who 
doesn't exist, my Postfix installation doesn't seem to notify the sender 
of the error, nor deliver a bounce message to the sender.


Log snippet of what I am talking about:

Sep 28 00:29:48 server2 dovecot: imap-login: Login: 
user=, method=PLAIN, rip=:::98.197.128.40, 
lip=:::69.164.197.129
Sep 28 00:29:58 server2 postfix/smtpd[3447]: connect from 
c-98-197-128-40.hsd1.tx.comcast.net[98.197.128.40]
Sep 28 00:29:58 server2 postfix/smtpd[3447]: NOQUEUE: reject: RCPT from 
c-98-197-128-40.hsd1.tx.comcast.net[98.197.128.40]: 550 5.1.1 
: Recipient address rejected: User unknown in 
virtual alias table; from= 
to= proto=ESMTP helo=
Sep 28 00:29:58 server2 postfix/smtpd[3447]: disconnect from 
c-98-197-128-40.hsd1.tx.comcast.net[98.197.128.40]



I am russ...@example.com. You can see that postfix notices that the user 
does not exist. However, I never get a message about it! No popup, no 
bounce message, nothing. This occurs on both Thunderbird and Windows 
Mail. Furthormore, Procmail's procmail.log also has no entries about any 
bounce message being delivered, so I know that the message isn't getting 
sneaked off to root or somewhere else it shouldn't be going.


On my older, production Exim server, ths popup occurs immediately.

Any ideas? Appreciate the help.