>Basically one fellow says his Postfix bounces back mail to the FROM: even >if it was spoofed, but his Postfix accepts the message completely before >even testing if the user was local. If not local then Postfix generates >the bounce.
correct, in that case, postfix or any MTA that accepts a msg but then can't deliver it must generate a new msg as a delivery failure notification to the envelope sender or the reply-to address. >Ive been following this thread and everyone says to config Postfix to not >bounce messages like that and that its a Bad Thing(tm). one of the few issues SPAM-L debating club agrees on. I see frequently 80 to 90+% msgs to unknown users. 10's or 100's of 1000's per day. Accepting all that volume, then generating a delivery failure msgs for them (to often forged, non-deliverable senders) would quickly swamp postfix deferred queue. insane >Our Postfix here is setup so any unknown RCPT TO: are rejected via >check_recipient_access. If the msg is not for one of your users, GAMEOVER. not one more byte or millisecond to waste on that SMTP session. >But I guess I'm missing something. > If a worm/person sends using a forged >FROM:, postfix rejects based on the check_recipient_access, is there no >bounce generated? nope, no new delivery failure notification msg is generated by the mailer-daemon. > Its just a reject, end of story. correct. but there is another situation where rejecting a msg is worse that DISCARDing it. first, the recipient is ok and no other smtpd restrictions REJECT the msg. so the DATA command is accepted and the cleanup process runs the header/body checks on the DATA. If the DATA is definitely a worm spew, then it's better to DISCARD the msg (drop in a black hole silently) rather than REJECT since you've already "bought" the bandwidth and postfix resources in accepting the DATA command. If the sender is legit server relaying worm spew from his legit users, then REJECTing it will cause THAT MTA mailer-daemon to generate a new msg back to the undeliverable forged or deliverable joe-jobbed innocent sender. Since you have already accepted the DATA, it's best to DISCARD the msg to prevent any more repercussions. >But if postfix was not using check_recipient_access, it would generate a >bounce back to the FROM: since it would have to accept the whole >message, check if the RCPT TO: was local etc, if not a local user, >bounce back to the From: even if it was forged. Is this correct? yes >I dont know if anyone else follows Spam-l, but for some reason my head is >swimming with this discussion and trying to wrap myself around it. spam-l is really a "watch me while I bring up a highly obscure point of discovery to demonstrate how overwhelmingly laser-like and encyclopedic my intelligence and knowledge are" debating club. When people use "I fear ..." or "I'm distressed that ...", I outta there. Note that the consensus on SPAM-L appears to be that SAV (call back, c/b) is an abomination, and SPF is bad. They are both worse than the problem they are trying to solve or reduce. >Basically want to make sure we are good neighbour and try to follow SOP >mail production. The whole point of check_reicipient_access used as early as possible in the smtpd restrictions is specifically to reject as soon as possible msgs to unknown recipients, (and CRA is different from other access maps in that it never returns an OK, only REJECT or DUNNO). This is the ONLY policy to follow. best for you, best for the (perhaps legit) sender (no DATA command), best for Internet. Len
