Re: How to bounce messages ?

At 19:22 2004-02-19 +0100, Ruud H.G. van Tol wrote:
> Unless you can reject it, before the accept.
Er, I believe that was what he was saying - rejecting it at the initial 
SMTP stage (EHLO -> MAIL FROM -> RCPT TO -> rejecto).  I run with delay 
checks in sendmail, so even when the sender isn't permitted to send, I'll 
see who the intended recipient was.  It also permits me to use the access 
db to bypass DNSBL checks, etc, and say, force an address to accept mail 
(such as for a user who might not otherwise agree with the use of DNSBLs, 
which is their prerogative - and a good idea for the ABUSE contact).
> See also rfc3461 "4.3 The RET parameter of the ESMTP MAIL command".
> Exchange and many other mailers like Notes always specify FULL.
Bugger too that some FORGED virus relayed through a random mail server is 
going to define the return type for you, rather than your own MTA 
configuration.  And of course, this data isn't passed along to the LDA, so 
when you bounce it at the LDA level (via procmail), you've got no idea that 
this was specified.

To the original requestor: I'm also of the opinion that you shouldn't 
bounce messages in the cases of apparent spam or viruses - in virtually 
every case you'll be causing more harm than benefit -- nowadays, viruses 
are often forged from an addressbook address or similar, so bouncing them 
sends them along to some other party who isn't to blame for the message; 
spam is forged or joe-jobbbed, AND even if the spammer address is legit, 
depending on how you sent the bounce, you might only confirm your address 
is legit.  In either case, you generate additional network traffic, and 
potentially incur a BOUNCE to your bounce attempt...
I send bounces from a discussion list preprocessor I wrote, which contains 
advisory text for the apparent sender of a message - executable file 
attachments are weeded out first so we're not harassing some poor sod with 
notices on that, but everything else is presumed to be going to a legit 
user - advising them how attachments aren't permitted, or their message 
appeared to be a direct response to a DIGEST subject instead of a regular 
reply, etc.

I do occasionally bounce messages for "USER UNKNOWN" stuff -- say, like 
when some nimrod recently used the address harvesting service "evite" to 
send an invitation to an event - I didn't have evite blocked at the SMTP 
level (I do now!), but wasn't keen on their systems figuring the address 
must be kosher (their so-called "privacy policy" explicitly says you can't 
remove your address from their db), so tickling the system to generate a 
syntactically correct user unknown bounce in response to the ALREADY 
RECEIVED messages seemed the best course of action.  This was done in the 
hopes that their system might recognize such bounces and nix addresses from 
their db, though the multiple attempts afterwards indicates that they 
probably don't do a damn thing with the bounces.
(For those that don't know, evite is owned by ticketmaster, and 
ticketmaster provides the email addresses of it's users to event promoters, 
etc, with no apparent limitations on what they can do with your address - a 
fine reason to use a throwaway webmail account for that sort of junk).
---
 Sean B. Straw / Professional Software Engineering

 Procmail disclaimer: <http://www.professional.org/procmail/disclaimer.html>
 Please DO NOT carbon me on list replies.  I'll get my copy from the list.


_______________________________________________
procmail mailing list
procmail(_at_)lists(_dot_)RWTH-Aachen(_dot_)DE
http://MailMan.RWTH-Aachen.DE/mailman/listinfo/procmail