Ed W wrote:
mouss wrote:
there are two cases:
- you enforce authentication and sender-login match. in this case, you detect forgeries
Lots of people like to allow authenticated users to send messages out with their own choice of FROM address (you paid for an smtp service - my opinion is that you should be allowed to use it for all your messages...). Possibly I misunderstand sender-login maps on postfix though and this is actually allowed (does it work by stopping you pretending to be another local user, but NOT limiting you from being a random other user, eg xxx@abcd.com ?)
you can use a map of allowed (login, sender) pairs. so a single login can have many authorized addresses.
if you allow any address, then that user can forge the address of someone else (including in yahoo, hotmail, ...). in this case, smtp is not the right way to implement the "copy to Sent" feature under discussion.
- you don't. in this case, you can't detect forgeries. and a header won't help. the whole approach breaks.
His point was that the header could be added at the client end - not all that scalable, but a good idea.
headers may be forged, so it's not secure either. but even if this is not a concern, you are asking users to add a header in their MUA! That's beyond the capacities of most users.
What seems to be missing from postfix (my understanding), but would be very useful, is a map which is based on authenticated sender name (we have maps based on FROM, but not authenticated user...) - this would allow stuff like more flexible restrictions on what a user can do based on the user themselves rather than the FROM address they are using... Possibly my misunderstanding though?
if you want access per login, then you need to implement this in a policy service. but in general, you don't want to allow a user to use an arbitrary sender address.
in an ISP environment, it is easier to setup multiple MSAs to implement different user classes.
The extra header field was being added presumably to identify real sent mail from faked spam and hence only add real sent messages to the sent folder?
and how do you add a header only to "really" sent mail? and anyway, how do you deliver a _copy_? remember that this is outgoing mail and won't naturally go through dovecot.
Perhaps I misunderstand the idea - but what I think was wanted was that every sent email from an authenticated sender would be bcc'd back to the person it came from. Then when it's being delivered back to the person who sent it (ie deliberate mail loop back) we detect that it's our own message "bouncing" back and stick it in the sent items folder instead of the inbox. The finesse is then reliably detecting which is which....
if mail is delivered to Sent folder instead of intended recipients, users will break your bones.
you can try whatever approach, but a COPY is needed so that the message goes both to the intended recipient AND to the Sent folder. and since the folder depends on the sender address, you need either sender bcc or pass all mail to a script or an LDA that will do the copy and resubmit the mail. but resubmitting mail this way is suboptimal.
The point raised later in the thread is that it's quite hard to detect mail being bcc'd back to us for putting in sent items and mail being dropped onto the server with a forged FROM address. As you correctly point out some restrictions on authenticated user help. The previous poster pointed out that hard to guess client headers inserted in all genuine email are also useful
you can put a header to detect forgeries if you like, but you should still use sender bcc to create a copy of outgoing mail.