Alan McKay a écrit :
>> Postfix will log all rejections AND BOUNCE permanent errors or queue
>> expiration ($maximal_queue_lifetime) mails. You also need some means
>> of handling the bounces.
>
> Could you elaborate on "some means of handling the bounces"?
unlist an address after some bounces. for this, you will probably need
VERP (if the bounce is received from a remote system, it is hard to find
out the recipient, because of "remote" aliases, forwarding, ...).
it is generally wise to use a mailing list manager (mailman and sympa
are good choices). because these already have a lot of functionality
that will make your life easier.
> A more directed question I have in that area is this. If I try to
> send, and the far end receives the mail no problem, but then at a
> later time - say, some minutes later after my server has said "ELOH"
> or whatever it is - how does the far end decide where to send the
> bounce? Will it do an MX lookup for the domain? In which case at
> present it will not find my Postfix server because I have no MX for
> it. Or will it remember my IP somehow, and bounce back there?
>
The bounce is sent to the envelope sender, the address that is put in
the MAIL FROM command (not headers).
http://en.wikipedia.org/wiki/Envelope_sender
If mail is an important subject for you (professionally or not), you
need to get a good understanding of how it works.
http://en.wikipedia.org/wiki/Simple_Mail_Transfer_Protocol
http://en.wikipedia.org/wiki/E-mail
>> Seriously, the main thing to avoid being considered a spammer is to
>> not send spam! That's all about your list management practices, and
>> has little to do with how you set up your mailer. If you are sending
>> UBE, you will (and should be) considered a spammer.
>
> We're currently having issues with Yahoo. We DO NOT send UBE. But
> invariably, every time you make something "idiot proof", the world
> invents a better idiot. We do have users who report us as spam for
> some odd reason.
This is a know problem (the "TIS button"). what really matters is the
ratio of mail reported as spam compared to the total received mail. but
for many providers, you need to get on their FBL (FeedBack Loop), or at
least fill their forms, ... etc. As long as you don't, they will
throttle and/or rate limit you.
> Our service is actually "white label" and people
> normally get it as a resold service from their financial institution.
> But the email comes from us, not from their institution. Well, we've
> just switched back to that model completely at my recommendation (I'm
> new here) because what we'd been doing before is that for some
> institutions we'd make the mails look like they came from that
> institution, but we did not do it in a very intelligent manner so they
> did have a spam footprint. (Duh!!!)
>
>> If you need help with that, the Spam-L mailing list can help:
>> http://spam-l.com/
>
> Thanks.
>
>> Google this mailing list for similar questions from similar bulk
>> senders. It comes up regularly.
>
> I'll try google. I did look at the archives before sending this, but
> did not find a search for it. Guess I should have been smart enough
> to use google for that though :-/
>
>> You're probably already on feedback loops with major receivers,
>> right? They might need to know that you're changing your mailer and
>> source IP address.
>
> That's another problem I've been having - trying to get the attention
> of the big guys. I've tried to contact Yahoo in the past with no
> luck. Though just tried again last week and finally got a response
> from them - if bulk. But at least it has some info on how I take the
> next step so I'm going through that.
>
> Somewhere in your response you alluded to an MX record for this new
> postfix box. I do not currently have one set up. Should I?
>
you need an MX for the domains you use in the envelope sender and
From/reply-To headers, not for a "box". The MX says which server to send
this or that mail to.
make sure you have a working postmaster and abuse addresses. google for
more infos ("list management best practices", ... etc).
> Thanks - I'll go digging in the archives to see what I can turn up.
> And will ask more questions in this thread if need be.
>
>
>
>
